Signals on Win32 (yet again)
От | Magnus Hagander |
---|---|
Тема | Signals on Win32 (yet again) |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE171580@algol.sollentuna.se обсуждение исходный текст |
Ответы |
Re: Signals on Win32 (yet again)
(Andrew Dunstan <andrew@dunslane.net>)
|
Список | pgsql-hackers-win32 |
Considering the input we've received lately, it looks like the option of making signal handlers thread safe is going to be really difficult. Likewise, finding "good places" to tuck in SleepEx calls is probaly not going to be easy. (I still think SleepEx and User APCs have to be a much faster and cleaner solutions than a hidden window - while rqeuiring the exact same thing which is a set of polling points) Which puts us back at the solution that uses a kernel driver to deliver signals/APCs. While it would be very nice to be able to do things in userspace only, that might just not be possible to do cleanly. And using the driver model will defintly make the modifications *of postgresql* smallest. Considering earlier comments of undocumented features etc, I tried to work through all the background material to that post (including the info where you had to register to get it). I've come up with the following points: 1) There are actually *two* implementations. a) Is the one references, that's on http://www.codeproject.com/threads/queueuserapcex.asp b) Is the one on http://www.windevnet.com/wdm/articles/2001/0108/ [free reg required] The main difference between these is that (a) uses the undocumented (see later point) ETHREAD structure, whereas (b) appears to only use documented kernel functions. (a) also supports "generic user APCs", whereas (b) only supports signal functions (or rather, anything which looks like it). 2) The ETHREAD structure is only semi-undocumented. See http://www.microsoft.com/mspress/books/sampchap/4354b.asp [this is from *the* guide to Win32 internals]. You can dump this structure from the kernel debugger. While not documented, you can at least get at it. The variable changed is clearly named "byte UserApcPending", so it should be easy to keep track of. It sholdn't be too hard to check if it's present at exactly that address in NT4, XP and 2003. The articles both list Inside Windows NT as the soruce, and it's still there in Windows 2000 according to the link above. This makes if feel quite a bit safer than I thought before. 3) Solution (a) is more generic, while still using less code in the kernel driver. In (a) the driver just sets the process to alertable. In (b) it actually calls the function. It should be possible to load and unload the driver "on the fly" from the postmaster assuming the user has permissions (for example, when running from commandline). As well as installing it in the system for automatic starting. It will completely remove the ability to run postgresql on a win32 box if you don't have *access* to an admin account (to install the driver). We'd probably need to ship the driver in binary format even for those that get the source distribution - a lot more people have the SDK to build programs than the DDK used to build drivers. Thoughts? //Magnus
В списке pgsql-hackers-win32 по дате отправления:
Предыдущее
От: "Merlin Moncure"Дата:
Сообщение: Re: Signals on Win32 (was RE: [HACKERS] [PATCHES] fork/exec patch)