select/APC/signals status update
От | Magnus Hagander |
---|---|
Тема | select/APC/signals status update |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE171636@algol.sollentuna.se обсуждение исходный текст |
Список | pgsql-hackers-win32 |
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
В списке pgsql-hackers-win32 по дате отправления: