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

Re: Reasoning behind process instead of thread based

From: Thomas Hallgren <thhal(at)mailblocks(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Reasoning behind process instead of thread based
Date: 2004-10-27 18:16:21
Message-ID: clooll$obb$ (view raw, whole thread or download thread mbox)
Lists: pgsql-general
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.

Thomas Hallgren

In response to

pgsql-general by date

Next:From: Tom LaneDate: 2004-10-27 18:21:53
Subject: Re: Bug: 8.0 beta1 either view optimization or pgdump/pgrestore
Previous:From: EricDate: 2004-10-27 18:14:25
Subject: QMail

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