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?
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?
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? 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.
Some documentation on what a worker is allowed to do would be helpful here..
- Heikki