From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | pgsql-hackers-win32 <pgsql-hackers-win32(at)postgresql(dot)org> |
Subject: | Re: Win32 signal code - first try |
Date: | 2004-01-08 23:38:00 |
Message-ID: | 3FFDE9D8.5020408@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers-win32 |
Magnus Hagander wrote:
>I think we agreed that we'd go with the polling method if it worked well
>enough, so we don't need a kernel driver. If that doesn't work out, the
>kernel driver would be the fallback method.
>
I think your code has almost certainly ruled out any necessity for a
kernel mode driver.
>
>Hmm. Depending on how often we need to poll (meaning how often we need
>to deliver signals), perhaps we can go with the WFSOEx method anyway.
>The code would be slightly easier:
>I've attached a version that uses this one instead.
>
>(You'd probably move the WaitFor()... call into the #define as well)
>
>Looking at this code, I'm thinking we can probably do away with the
>critical section alltogether. All that code now executes on the main
>thread. Does this seem correct?
>
>
>
I understood your first version better than I understand this one. What
calls __pg_poll_signals()? As I understand the first version, we
wouldn't need to put any polling calls into the main thread code - the
signal detector would just queue a call to pg_signal_apc() on the main
thread as needed, which would in turn do some cleanup and call the
signal handler. That seems to me to be *very* clean and nice. Am I
missing something? (As you can no doubt tell, IANAWP :-) )
BTW, well done!
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Natoli | 2004-01-09 00:14:18 | Re: Signals on Win32 (yet again) |
Previous Message | Andrew Dunstan | 2004-01-08 22:53:20 | Re: Win32 signal code - first try |