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

> -----Original Message-----
> From: Magnus Hagander [mailto:mha(at)sollentuna(dot)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.

Dann Corbit wrote:

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

Isn't WaitForSingleObject() in effect a polling call?

cheers

andrew