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$1@sea.gmane.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

Regards,
Thomas Hallgren

In response to

Browse pgsql-general by date

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