PEP 3143 and customizations

[Helmut Grohne]

On Wed, May 21, 2014 at 09:50:02AM -0700, Ethan Furman wrote:
> 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

The name "parent_callback" is misleading, because the callback must be
executed in the child process. If it were to be executed in the parent
and were to initialize a thread, then the exiting of the parent were to
terminate the newly spawned thread. Not the desired outcome.

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

Would open be calling the .finished() method?

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

Both variants have the advantage of mostly retaining backwards
compatibility at the cost of being hard to use. Being able to continue
initialization after having called .open() would be far easier to use.
Consider a different change:

The .open() method gains a keyword parameter "exitparent" defaulting to
True. If False is passed, a pipe is created prior to the background
fork. Rather than exiting, the parent reads from that pipe. A new
.exitparent() method is provided and must be called after .open() when
exitparent=False. It closes the write end of the pipe and thereby causes
the parent to exit. Optionally an error message can be given to
.exitparent() in which case the error message is passed through the
pipe, causes the parent to print the error and exit with a failure
status code.

A POC is attached.

(Please keep CCing me.)

Helmut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: daemon.py.diff
Type: text/x-diff
Size: 2958 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/python-daemon-devel/attachments/20140521/e548edd9/attachment.diff>