Re: [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database)

Heikki Linnakangas escribió:
> On 22.11.2012 19:18, Alvaro Herrera wrote:
> >Heikki Linnakangas escribió:
> >>On 21.11.2012 23:29, Alvaro Herrera wrote:
> >>>Alvaro Herrera escribió:
> >>>>The UnBlockSig stuff is the main stumbling block as I see it because it
> >>>>precludes compilation on Windows.  Maybe we should fix that by providing
> >>>>another function that the module is to call after initialization is done
> >>>>and before it gets ready to work ... but having a function that only
> >>>>calls PG_SETMASK() feels somewhat useless to me; and I don't see what
> >>>>else we could do in there.
> >>>
> >>>I cleaned up some more stuff and here's another version.  In particular
> >>>I added wrapper functions to block and unblock signals, so that this
> >>>doesn't need exported UnBlockSig.
> >>
> >>Could you just unblock the signals before calling into the
> >>background worker's main() function?
> >
> >Yes, but what if a daemon wants to block/unblock signals later?
>
> Ok. Can you think of an example of a daemon that would like to do that?

Not really, but I don't know what crazy stuff people might be able to
come up with.  Somebody was talking about using a worker to do parallel
computation (of queries?) using FPUs, or something along those lines.  I
don't have enough background on that sort of thing but it wouldn't
surprise me that they wanted to block signals for a while when the
daemons are busy talking to the FPU, say.

> Grepping the backend for "BlockSig", the only thing it seems to be
> currenlty used for is to block nested signals in the SIGQUIT handler
> (see bg_quickdie() for an example). The patch provides a built-in
> SIGQUIT handler for the background workers, so I don't think you
> need BlockSig for that. Or do you envision that it would be OK for a
> background worker to replace the SIGQUIT handler with a custom one?

I wasn't really considering that the SIGQUIT handler would be replaced.
Not really certain that the SIGTERM handler needs to fiddle with the
sigmask ...

> Even if we provide the BackgroundWorkerBlock/UnblockSignals()
> functions, I think it would still make sense to unblock the signals
> before calling the bgworker's main loop. One less thing for the
> background worker to worry about that way. Or are there some
> operations that can't be done safely after unblocking the signals?

Yes, that's probably a good idea.  I don't see anything that would need
to run with signals blocked in the supplied sample code (but then they
are pretty simplistic).

> Also, I note that some worker processes call sigdelset(&BlockSig,
> SIGQUITE); that remains impossible to do in a background worker on
> Windows, the BackgroundWorkerBlock/UnblockSignals() wrapper
> functions don't help with that.

Hmm.  Not really sure about that.  Maybe we should keep SIGQUIT
unblocked at all times, so postmaster.c needs to remove it from BlockSig
before invoking the bgworker's main function.

The path of least resistance seems to be to export BlockSig and
UnBlockSig, but I hesitate to do it.

> Some documentation on what a worker is allowed to do would be helpful
> here..

I will see about it.

If the bgworker developer gets really tense about this stuff (or
anything at all, really), they can create a completely new sigmask and
do sigaddset() etc.  Since this is all C code, we cannot keep them from
doing anything, really; I think what we need to provide here is just a
framework to ease development of simple cases.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services