PEP 3143 and customizations

Helmut Grohne h.grohne at cygnusnetworks.de
Tue Jan 29 09:35:42 UTC 2013


Please continue to CC me in reply.

On 28.01.2013, at 07:02, Ben Finney <ben+python at benfinney.id.au> 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.

Helmut




More information about the python-daemon-devel mailing list