Re: Win32 signal code - first try
От | Claudio Natoli |
---|---|
Тема | Re: Win32 signal code - first try |
Дата | |
Msg-id | A02DEC4D1073D611BAE8525405FCCE2B55F244@harris.memetrics.local обсуждение исходный текст |
Ответы |
Re: Win32 signal code - first try
|
Список | pgsql-hackers-win32 |
> > Magnus Hagander writes: > > > > Firstly, I think the WaitForMultipleObjectsEx call in > > > > __pg_poll_signals is bogus. You're probably after > > > > SleepEx(0,TRUE), or something of the like. [snip] > No. The NT scheduler works on thread level, not process level. Threads > are scheduled completely independent of their processes. This means we > yield to another thread *in any process in the system*. Which > makes all the difference, I think. In any case, getting back to the original point, your WaitForMultipleObjectEx call as written returns 0xFFFFFFFF, which clearly indicates it is in error. If you don't want to use SleepEx (which, I really think will be ok), you'll need come up with some other alternative. The obvious one is to issue a WaitFor* on a dummy handle which never gets signalled, but, between that and SleepEx, well, you get the picture :-) > > [aside: you can raise + catch SIGINTs under NT, but a new > thread gets > created to handle the call] > > Yes, but you can't use signal() etc for it, you have to use > SetConsoleCtrlHandler(). Actually, you really can signal for it. And I am familiar with this line of the docs: "Note SIGINT is not supported for any Win32 application including Windows NT and Windows 95. When a CTRL+C interrupt occurs, Win32 operating systems generate a new thread to specifically handle that interrupt. This can cause a single-thread application such as UNIX, to become multithreaded, resulting in unexpected behavior." By "not supported", it means, not supported in the usual sense of signal (ie. interrupt and begin execution at the signal point). However, if you set up a signal handler for SIGINT, that new thread which runs will run the specified handler. Try a 10 line test program for yourself if you like... However, this is all moot and a bit OT. > Also remember that in most cases, the server will not run on a console > but as a service - I don't think you'll ever get SIGINT then. In any case, I still think it'd be nice to grab Ctrl-Cs with a SetConsoleCtrlHandler, but we are getting ahead of ourselves :-) [BTW, I'm nearly always running postgres from a console] > The documentation of signal() clearly states: > The SIGILL, SIGSEGV, and SIGTERM signals are not generated under Windows > NT. They are included for ANSI compatibility. > SIGINT is not supported for any Win32 application Again, not generated, but can be raised. But, like I said, this is all a bit moot, as the only way to raise are via an in-process raise() call, and such raise calls would end up being routed through your signal handling code anyway. As I said, just for completeness... > Otherwise, we just have to test. I'll see if I can cook something up > during the weekend unless someone beats me to it (or better yet, finds > the docs). Cool! One final comment, having had a chance to go through the code a bit more thoroughly. Just wondering if the logic for signal blocking is correct. Under Unix, IIRC, if a signal is blocked when raised, it will (might?) be delivered when that sigmask is unblocked. In the current implementation, it 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). 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>
В списке pgsql-hackers-win32 по дате отправления: