> -----Original Message----- > From: mlw [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 03, 2003 12:47 PM > To: Shridhar Daithankar > Cc: PGHackers > Subject: Re: [HACKERS] Threads > > > Please no threading threads!!! > > Has anyone calculated the interval and period of "PostgreSQL needs > threads" posts? > > The *ONLY* advantage threading has over multiple processes is > the time > and resources used in creating new processes.
Threading is absurdly easier to do portably than fork(). Will you fork() successfully on MVS, VMS, OS/2, Win32? On some operating systems, thread creation is absurdly faster than process creation (many orders of magnitude). > That being said, I admit that creating a threaded program is > easier than > one with multiple processes, but PostgreSQL is already there > and working. > > Drawbacks to a threaded model: > > (1) One thread screws up, the whole process dies. In a > multiple process > application this is not too much of an issue. If you use C++ you can try/catch and nothing bad happens to anything but the naughty thread. > (2) Heap fragmentation. In a long uptime application, such as a > database, heap fragmentation is an important consideration. With > multiple processes, each process manages its own heap and what ever > fragmentation that exists goes away when the connection is closed. A > threaded server is far more vulnerable because the heap has to manage > many threads and the heap has to stay active and unfragmented in > perpetuity. This is why Windows applications usually end up > using 2G of > memory after 3 months of use. (Well, this AND memory leaks) Poorly written applications leak memory. Fragmentation is a legitimate concern. > (3) Stack space. In a threaded application they are more > limits to stack > usage. I'm not sure, but I bet PostgreSQL would have a problem with a > fixed size stack, I know the old ODBC driver did. A single server with 20 threads will consume less total free store memory and automatic memory than 20 servers. You have to decide how much stack to give a thread, that's true. > (4) Lock Contention. The various single points of access in a process > have to be serialized for multiple threads. heap allocation, > deallocation, etc all have to be managed. In a multple process model, > these resources would be separated by process contexts. Semaphores are more complicated than critical sections. If anything, a shared memory approach is more problematic and fragile, especially when porting to multiple operating systems. > (5) Lastly, why bother? Seriously? Process creation time is an issue > true, but its an issue with threads as well, just not as bad. > Anyone who > is looking for performance should be using a connection pooling > mechanism as is done in things like PHP. > > I have done both threaded and process servers. The threaded > servers are > easier to write. The process based severs are more robust. From an > operational point of view, a "select foo from bar where x > > y" will take > he same amount of time. Probably true. I think a better solution is a server that can start threads or processes or both. But that's neither here nor there and I'm certainly not volunteering to write it. Here is a solution to the dilemma. Make the one who suggests the feature be the first volunteer on the team that writes it. Is it a FAQ? If not, it ought to be. ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
