Re: [HACKERS] [PATCHES] fork/exec patch

> > 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