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