Re: [HACKERS] [PATCHES] fork/exec patch
От | Magnus Hagander |
---|---|
Тема | Re: [HACKERS] [PATCHES] fork/exec patch |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE171573@algol.sollentuna.se обсуждение исходный текст |
Список | pgsql-hackers-win32 |
> Steve Tibbett wrote: > > Here's another option - what about using a named pipe? If > you want to > > send the process a signal, you open the named pipe, write a single > byte > > to it (the signal value) and close the pipe. > > > > The server process would launch a thread on startup which > would create > > the server side of the pipe and then do an infinite wait on > the pipe > > handle. When the wait returns, it would reads a byte and takes that > > signal action - > > if the read failed, then it means the main thread has > closed the pipe > > handle > > because it's shutting down, so it would set an event and > thread would > > terminate. > > I like this idea a lot. I admit though I have to do a little research > to give a better informed opinion. My feelings wrt messages > were based > on a general uneasiness surrounding WaitForSingleObject calls > via a polling thread, because this will exhibit pseudo-random > (thus difficult to debug) behavior. Messages allow you to > avoid this in simple cases by returning to the callback > occasionally or even checking the message queue in some smart > places. However, yours and Magnus's objections are valid. > > Named pipes are better though but IIRC are NT only, which > actually I consider to be a Good Thing. They are also more > unixish in design than either events or messages, which is > also a Good Thing. Definitely worth a second look. Named Pipes certainly has a bit more elegance to it, since you have only one object and not both an event and shared memory. You could even use an anonymous pipe instead. They work on both 9x and NT (if you should want it). On NT, it's implemented under the hood using Named Pipes. Personally, I like the separate thread part because it makes it pick up the signal real fast, so there is no risk of blocking the signal *sender*. And if you need to poll somewhere, it has to be better to do it outside the thread. You need some decent synchronization around the shared structures used inside the backend, but since it's just threads in the same process at that time, a simple CriticalSection should be enough. But this holds wether you use named pipes or events. Since the current signal handlers are already used to being called while in another routine (except when signals are blocked, of course) they shuold be ready to handle being called in the middle of anywhere. The main issue with that one is *when* the main thread will be in alertable state. According to the docs, this will happen on SleepEx, WaitForSingleObjectEx, WaitForMultipleObjectsEx, SignalObjectAndWait and MsgWaitForMultipleObjectsEx will put it there. So either you have to call those explicitly, or the C library or NT itself will have to call them at some point (for example, when waiting for I/O). A quick test program that runs in an infinite loop reading a file shows that the thread does *not* enter alertable state just from that normal I/O :-( I need to add an explicit SleepEx(0) to make it do that... Which means that if you both need to execute the signal handler on the main thread, and don't want to mess around with exceptions, you need to add polling somewhere in the main thread anyway. //Magnus
В списке pgsql-hackers-win32 по дате отправления: