Re: Reasoning behind process instead of thread based

Tom Lane wrote:
> 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 just arguing that far from all signals are caused by unrecoverable 
errors and that threads causing them can be killed individually and 
gracefully.

I can go further and say that in some multi-threaded environments you as 
a developer don't even have the opportunity to corrupt memory. In such 
environments the recognized traps are the only ones you encounter unless 
the environment is corrupt in itself. In addition, there are a number of 
techniques that can be used to make it impossible for the threads to 
unintentionally interfere with each others memory.

I'm not at all contesting the fact that a single-threaded server 
architecture is more bug-tolerant and in some ways easier to manage. 
What I'm trying to say is that it is very possible to write even better, 
yet very reliable servers using a multi-threaded architecture and high 
quality code.

> ... The point here is circumscribing how much can go wrong before you
 > realize you're in trouble.
> 
Ok now I do follow. With respect to my last comment about speed, I guess 
it's long overdue to kill this thread now. Let's hope the forum stays 
intact :-)

Regards,
Thomas Hallgren