Win32 signals code, take two
От | Magnus Hagander |
---|---|
Тема | Win32 signals code, take two |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE2A6B7C@algol.sollentuna.se обсуждение исходный текст |
Список | pgsql-hackers-win32 |
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: 1) pg_signal_initialize()? 2) PG_POLL_SIGNALS()? 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 :-) //Magnus
Вложения
В списке pgsql-hackers-win32 по дате отправления: