Skip site navigation (1) Skip section navigation (2)

Re: Reasoning behind process instead of thread based

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Hallgren <thhal(at)mailblocks(dot)com>
Cc: nd02tsk(at)student(dot)hig(dot)se, pgsql-general(at)postgresql(dot)org
Subject: Re: Reasoning behind process instead of thread based
Date: 2004-10-27 22:59:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
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

In response to


pgsql-general by date

Next:From: Ed L.Date: 2004-10-27 23:01:45
Subject: WARNING: column "footype" has type "unknown"
Previous:From: Michael FuhrDate: 2004-10-27 22:52:28
Subject: Re: interval to seconds conversion. How?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group