> -----Original Message-----
> From: Magnus Hagander [mailto:mha@sollentuna.net]
> Sent: Tuesday, December 16, 2003 7:53 AM
> To: Andrew Dunstan; PostgreSQL-development; pgsql-hackers-win32
> Subject: Re: [pgsql-hackers-win32] [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.
By using events you don't have to poll at all. You are waiting on the
event. A signal fires the event. It is also possible to add as many
signal types as you like, even beyond the standard UNIX batch if it
suits your fancy.