Hi!
Here's a summary of the summary of my communications with MS on the
handling of APCs in recv() and send() (we've alreayd dealt with select()
earlier):
"
I'm afraid the solution to not be very very secure. To be honest I
strongly discourage you from using this implementation since we can not
guarantee that you will not loose some data if recv() is interrupted
and/or the thread preempted by the system at a critical moment. "
Based on this, I see only two possible solutions:
1) Replace all "old style socket calls" with Winsock 2 (WSAxxx)
functions, that can handle this. This can be done by #define:ing them
and write wrappers.
2) Stop using APCs for signals.
(1) carries a big problem - if we do this, we can *not* support SSL on
win32, because it uses recv() and send() internally (inside the openssl
library). Therefor, I don't think (1) is really an option - at least not
in the long run.
As for (2), when writing the original signals code, it was designed to
be fairly easily replaced with a method not using APCs (there was a lot
of discussion back then).
Going with (2) will require us to put "signal aware" code at every point
where we want signals delivered. This means we have to write the
wrappers for all the signals codes anyway, no way around that (it needs
to block on both signal-delivered and socket-action). We already put a
Wait..() function in the CHECK_FOR_INTERRUPTS, that one just needs to be
changed. Semaphore code and sleeping code also need to have their Wait
functions changed, but that's simple.
The only complicated part I see there is the "write our own select() and
friends". I have much of that done, and it appears to work. It is a bit
of code, but not too bad.
I feel this is the way to go. Relying on APCs to interrupt socket calls
is just not safe - they are not meant to support it. The other option
that is left is the "create an exception on the thread and catch it"
used by e.g. cygwin, but we decided early on that this is a last-attempt
hack, because it's way ugly.
My plan is to write up an implementation of signals using events instead
of APCs, and wrapper functions for the socket functions that live with
this one. Initially I will not fix the SSL issues, but I'm quite sure
that it's doable using this method (with wrappers, again).
While doing this, I'll also move the win32 specific code from pqsignal.c
into port/win32.
//Magnus