> -----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
> (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

Reply via email to