Re: Win32 signals code, take two
От | Merlin Moncure |
---|---|
Тема | Re: Win32 signals code, take two |
Дата | |
Msg-id | 303E00EBDD07B943924382E153890E5434AA67@cuthbert.rcsinc.local обсуждение исходный текст |
Ответ на | Win32 signals code, take two ("Magnus Hagander" <mha@sollentuna.net>) |
Список | pgsql-hackers-win32 |
Magnus Hagander wrote: > > Magnus Hagander wrote: > > > Here's an updated version of the proposed win32 signals > > code, with the > > > following main changes: > > > > One small possible revision to consider: As I read the code, > > all manipulation to pg_signal_queue is inside a > > CriticalSection, and it is only set (> 0) when there are > > pending signals. > > > > ISTM that pg_queue_signal can abort without calling > > QueueUserAPC pg_signal_queue is already set. This will keep > > the dispatch function from getting called extra times. > > Paranoia statement > > > > pg_signal_queue = 0; > > > > could possibly be added at the end of the dispatch. > > No, I don't think it can't. Consider delayed signals. When leaving the > dispatch function, pg_signal_queue may very well be != 0. Only > (pg_signal_queue & ~pg_signal_mask) should be zero. Yep...my bad. > Also, I think it's best if the mask is checked upon signal *delivery*, > not queueing. The signal could be blocked when delivered and non-blocked > on delivery. If we never queue a APC in this case, the signal will be > lost. But we *could* do the check in pg_signal_queue, but then against > (pg_signal_queue &~ pg_signal_mask). Right...that is safer. I still think there may be a more sophisticated check in there...if any executable signal is already pending, then you can count that you are either in a dispatch or that dispatch is already queued. Merlin
В списке pgsql-hackers-win32 по дате отправления: