> > If you need a response once it has actually run, then the > main thread > > needs to do signal polling now and then. This has the bad > sideeffect > > that the main thread will block completely until the signal is > > delivered, which might be a while. > > > > I don't know what the semantics are for kill() on unix > there? And if > > it is sync, does postgresql actually need that property? > > > > kill() should return success upon the signal being queued, as I > understand it - i.e. no sync.
Ok. That makes things a lot easier. THen it's just the question of how fast we need to react. > All this kind of answers my original question, by pointing > out the need > to poll one way or another, which is why I suggested that signal > emulation might be messy, and more complicated than the > fork/exec case. That definitly makes it more complicated. However, IIRC the thread will enter an "alerable state" at least for network I/O, and probably for disk I/O. Can't seem to find a reference to this, though. If you use queued user APCs (using QueueUserAPC()), from a separate signal-handling thread, this should dispatch the signal handlers *fairly* fast. The question is if "fairly fast" is good enough, or if "really fast" is needed? In that case, you might have to work either with poll-really-often (ickk), or using manual thread exceptions (raelly messy). It shouldn't need to be *too* messy, if you can live with possible slowdowns (assuming the thread does go alertable on blocking I/O). Possibly add a WaitForSingleObject() at some place in a loop to force it there in some cases. Looking some more on the os-fix2.cpp file (I read the thing as OS2 fix, and thus ignored it), it seems they fire all signal handlers on a thread of their own. Is the backend threadsafe enough that that is safe? If so, that would do away with the nede to use QueueUserAPC() to make the call execute on the main thread. //Magnus ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html