Re: Reasoning behind process instead of thread based

Поиск
Список
Период
Сортировка
От Thomas Hallgren
Тема Re: Reasoning behind process instead of thread based
Дата
Msg-id clooll$obb$1@sea.gmane.org
обсуждение исходный текст
Ответ на Re: Reasoning behind process instead of thread based  (nd02tsk@student.hig.se)
Список pgsql-general
nd02tsk@student.hig.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

В списке pgsql-general по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Reasoning behind process instead of thread based
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: what could cause inserts getting queued up and db locking??