Signals on Win32 (yet again)

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