Here's an updated version of the proposed win32 signals code, with the
following main changes:
* Now uses names and defines already in pqsignal.h when available - this
is where it will end up after all. Only changes names.
* The signal listener threads now creates separate threads to read/write
on the pipe, to make sure we don't hang anywhere there. I put the
ReadFile() in the separate thread as well (to be sure). It does not pose
any different synchronisation issues than we had before.
* The signal queue is now kept as a bitmask.
* Signals queued while blocked are now delivered once unblocked
* Default signals are now handled. They're all set to SIGIGN, because I
haven't figured out what to put in there :-)
* Signals can now be delivered at two locations: From a User APC queued
by the signal handling thread, or when calling sigsetmask() and
unblocking a signal that has been queued.
* PG_POLL_SIGNALS() now does WaitForSingleObjectEx() on an object that
actually exists, so no error is given.
Those are the majors :-)
Claudio, in your other working on the backend, have you by any chance
identified good places to do:
Also, another question on the interface: Right now throughout the
backend, pqsignal() is used to modify signals, and not signal()
directly. But sigsetmask(), kill() etc are called directly. Should we go
with that, and as now just define our own, or should we change to
pgsigsetmask(), pgkill() etc, and then change taht all over the code?
Which is the preferred way?
Apart from those, comments in general? I hope I managed to include all
the things discussed since last time :-)
Description: application/octet-stream (2.6 KB)
Description: application/octet-stream (6.0 KB)
pgsql-hackers-win32 by date
|Next:||From: Claudio Natoli||Date: 2004-01-19 13:03:09|
|Subject: Re: Win32 signals code, take two|
|Previous:||From: Magnus Hagander||Date: 2004-01-16 13:53:31|
|Subject: Re: Win32 signal code - first try|