PEP 3143 and customizations

[Ethan Furman]

Helmut Grohne wrote:
>
> Please continue to CC me in reply.
>
> On 28.01.2013, at 07:02, Ben Finney wrote:
>>
>> The ‘DaemonContext’ class is designed to allow overriding behaviour through
>> subclassing and the ‘super()’ mechanism, so I'm not sure what you would
>> need monkey-patching for. Can you give a concrete example which can't be
>> addressed by a custom ‘DaemonContext’ subclass?
>
> I gave this example in my previous mail. It was about some initialization to
> be done after daemonizing and only then terminating the parent. This is
> currently hard or impossible to achieve with DaemonContext. An attempt to do so
> would subclass DaemonContext and provide an own open method. But it cannot call
> DaemonContext.open, because that would terminate the parent process. So my
> subclass has to copy most of DaemonContext.open or monkey-patch the original
> one. If you disagree maybe you can fill in the missing bits in the pseudo code
> below?
>
> class CustomDaemonContext(DaemonContext):
>
>     def finish(self, error_message=None):
>         if error_message:
>             pass # Let the parent print the error message and exit non-zero.
>         else:
>             pass # Let the parent exit with a zero status.
>
>
> context = CustomDaemonContext()
>
> initial_setup()
>
> with context:
>     try:
>         fork_worker_child()
>     except WorkerSpawnFailure:
>         context.finish("failed to spawn worker")
>     else:
>         context.finish()
>
>     do_main_program()
>
> Please observe that the worker cannot be spawned within initial_setup, because the
> fork performed in DaemonContext.open would detach that child from the process and
> receiving SIGCHLD would no longer work.

I see two ways around this, both enhancements to daemon.py:

   - have __init__ accept a parent_callback parameter which will be called
     after the child is forked but before exiting

   - have a stub method (such as .finished()) that is always called after
     the child is forked but before the parent exits, which can then be
     overridden in subclasses

I would prefer the first option as that would make subclassing unnecessary.

--
~Ethan~