Skip site navigation (1) Skip section navigation (2)

Re: Reasoning behind process instead of thread based

From: "Dann Corbit" <DCorbit(at)connx(dot)com>
To: <pgsql-general(at)postgresql(dot)org>
Subject: Re: Reasoning behind process instead of thread based
Date: 2004-10-27 18:34:34
Message-ID: D425483C2C5C9F49B5B7A41F894415470555E7@postal.corporate.connx.com (view raw or flat)
Thread:
Lists: pgsql-general
> -----Original Message-----
> From: pgsql-general-owner(at)postgresql(dot)org 
> [mailto:pgsql-general-owner(at)postgresql(dot)org] On Behalf Of 
> Thomas Hallgren
> Sent: Wednesday, October 27, 2004 11:16 AM
> To: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] Reasoning behind process instead of 
> thread based
> 
> 
> nd02tsk(at)student(dot)hig(dot)se wrote:
> >>Two:  If a
> >>single process in a multi-process application crashes, that process 
> >>alone dies.  The buffer is flushed, and all the other child 
> processes 
> >>continue happily along.  In a multi-threaded environment, when one 
> >>thread dies, they all die.
> > 
> > 
> > 
> > So this means that if a single connection thread dies in MySQL, all 
> > connections die?
> > 
> > Seems rather serious. I am doubtful that is how they have 
> implemented 
> > it.
> > 
> That all depends on how you define crash. If a thread causes an 
> unhandled signal to be raised such as an illegal memory access or a 
> floating point exception, the process will die, hence killing all 
> threads. But a more advanced multi-threaded environment will install 
> handlers for such signals that will handle the error gracefully. It 
> might not even be necesarry to kill the offending thread.
> 
> Some conditions are harder to handle than others, such as 
> stack overflow 
> and out of memory, but it can be done. So to state that 
> multi-threaded 
> environments in general kills all threads when one thread chrashes is 
> not true. Having said that, I have no clue as to how advanced 
> MySQL is 
> in this respect.

There are clear advantages to separate process space for servers.
1.  Separate threads can stomp on each other's memory space.  (e.g.
imagine a wild, home-brew C function gone bad).
2.  Separate processes can have separate user ids, and [hence] different
rights for file access.  A threaded server will have to either be
started at the level of the highest user who will attach or will have to
impersonate the users in threads.  Impersonation is very difficult to
make portable.
3.  Separate processes die when they finish, releasing all resources to
the operating system.  Imagine a threaded server with a teeny-tiny
memory leak, that stays up 24x7.  Eventually, you will start using disk
for ram, or even use all available disk and simply crash.

Threaded servers have one main advantate:
Threads are lightweight processes and starting a new thread is faster
than starting a new executable.

The thread advantage can be partly mitigated by pre-launching a pool of
servers.

Responses

pgsql-general by date

Next:From: Froggy / Froggy Corp.Date: 2004-10-27 18:43:02
Subject: Re: Problème de threadPostgresql
Previous:From: Daniel VeriteDate: 2004-10-27 18:33:12
Subject: Re: Problème de thread

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group