Re: Win32 signals code, take two

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: Win32 signals code, take two
Date: 2004-01-19 14:36:18
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE1715A5@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32

> 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.

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).

//Magnus

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Merlin Moncure 2004-01-19 14:54:25 Re: Win32 signals code, take two
Previous Message Merlin Moncure 2004-01-19 14:24:15 Re: Win32 signals code, take two