>>>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
threadsafe.
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.
//Magnus