Re: Reasoning behind process instead of thread based

Thomas Hallgren <thhal(at)mailblocks(dot)com> writes:
> Tom Lane wrote:
>> Right. Depending on your OS you may be able to catch a signal that
>> would kill a thread and keep it from killing the whole process, but
>> this still leaves you with a process memory space that may or may not
>> be corrupted.

> It is very common that you either get a null pointer exception (attempt
> to access address zero), that your stack will hit a write protected page
> (stack overflow), or that you get some sort of arithemtic exception.
> These conditions can be trapped and gracefully handled.

That argument has zilch to do with the question at hand. If you use a
coding style in which these things should be considered recoverable
errors, then setting up a signal handler to recover from them works
about the same whether the process is multi-threaded or not. The point
I was trying to make is that when an unrecognized trap occurs, you have
to assume not only that the current thread of execution is a lost cause,
but that it may have clobbered any memory it can get its hands on.

> I'm not sure I follow. You will be able to bring all threads of one
> process to a halt much faster than you can kill a number of external
> processes.

Speed is not even a factor in this discussion; or do you habitually
spend time optimizing cases that aren't supposed to happen? The point
here is circumscribing how much can go wrong before you realize you're
in trouble.

regards, tom lane