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

Re: [HACKERS] [PATCHES] fork/exec patch

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>,"pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCHES] fork/exec patch
Date: 2003-12-16 20:35:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
>>>Isn't WaitForSingleObject() in effect a polling call?
>>It puts your thread to sleep, until it gets woken up by the handle
>>you're waiting on being set to a signalled state.
>Right. Just like select() puts your thread to sleep until one of its 
>files is ready (or it times out).
>Do we have a terminology problem here?
>The point is that, unlike classic Unix signal programming, you need 
>*something* that explicitly checks for the event. It could be 
>a separate 
>thread in a tight loop, which is what the CONNX code appears to do, or 
>it could conceivably be something else in the main thread with a very 
>short timeout.

Yes, if you include the wait...() in the tight loop, which means it will
spend 99.999% of it's time in sleeping state (kernel blocked). But yes,
in some way it has to go back into the main thread. Either through some
kind of polling or through exception. Unless the handlers are

I know at least the SIGHUP handler in pgsql (backend/tcop/postgres.c)
just sets a flag in the signal handler, which could be easily protected
(this flag is polled in the main loop). The comments seem to indicate
the idea that complex signal handlers = bad. I guess we need to check
out the other signal handlers - if they're that easy, then it's a
non-point and they can really easy be made thread-safe.



pgsql-hackers-win32 by date

Next:From: Steve TibbettDate: 2003-12-16 20:48:14
Subject: Re: [HACKERS] [PATCHES] fork/exec patch
Previous:From: Andrew DunstanDate: 2003-12-16 20:20:53
Subject: Re: [pgsql-hackers-win32] [PATCHES] fork/exec patch

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