Re: Win32 signal code - first try

From: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
To: 'Merlin Moncure' <merlin(dot)moncure(at)rcsonline(dot)com>, Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>, Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: pgsql-hackers-win32 <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: Win32 signal code - first try
Date: 2004-01-09 15:21:50
Message-ID: A02DEC4D1073D611BAE8525405FCCE2B55F245@harris.memetrics.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32


Merlin Moncure:
> > looks as though blocked signals will be forever lost. If I'm right in my
> > recollection, we'll need some way to requeue the APC (which might be
> > non-trivial).
>
> Perhaps it would be easier to hold up the QueueAPC with a manual-switch
> event object until the signal handler is cleared to run.

That's a neat idea, but just have to be very careful here. Currently, the
code does a ReadFile, queues the signal, and then a WriteFile. Calls to
raise and/or kill to a process with a blocking signal queuing, as written,
would fail, and take up to a second to do so.

Also, and more pertinently, you may want to block some signals, but allow
others through. Not sure how you imagine this would be handled, at least
with a single event object, although perhaps I've misunderstood your intent.

Cheers,
Claudio

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Merlin Moncure 2004-01-09 16:35:33 Re: Win32 signal code - first try
Previous Message Merlin Moncure 2004-01-09 13:33:13 Re: Win32 signal code - first try