[Python-ideas] Draft PEP: Standard daemon process library]

[Trent Nelson]

On Wed, Jan 28, 2009 at 01:48:46PM +1100, Ben Finney wrote:
> Trent Nelson writes:
> 
> > On Tue, Jan 27, 2009 at 08:49:52PM -0500, Jesse Noller wrote:
> > > Windows Services != Unix daemons. Admittedly, I haven't had to do
> > > it in awhile, but from what I remember, windows services are
> > > nowhere near the same type of beast as a unix daemon, and trying
> > > to make a unified daemon library that glosses over the differences
> > > might cause seizures and habitual smoking.
> > > 
> > > A unix-only daemon - and then a complimenting windows-only service
> > > library - makes sense. Ideally, they would have close to the same
> > > API, but I don't think log jamming all of the vagaries of both
> > > into one beast makes sense. Then again, my windows-ability is out
> > > of date and rusty.
> > 
> > See, I disagree with that as well.  Take a look at what Qt did with
> > their QtService class:
> > 
> >     http://doc.trolltech.com/solutions/qtservice/qtservice.html
> 
> Thanks for mentioning that again; I saw another reference to it
> earlier, but didn't respond.
> 
> > I'd like to hear arguments for why that QtService interface is
> > perceived as being deficient.
> 
> Off the top of my head:
> 
> The QtService model seems to be ???start an additional process and
> maintain it at arms length, with a bunch of communication channels
> into and out of it???. Contrariwise, this PEP addresses the use case of
> ???turn the *current* program into a daemon process, so that everything
> further this program does is running inside that process???.

    What are you left with at the end of the day?  Something you can 
    start, stop, query status, and log out and have it still run.  How
    you got there (daemonising the current process) surely isn't as
    important as where you ended, especially if it nukes any chance
    of cross-platformness?

> It's too big, as a result of the above difference in focus. When
> writing a Unix daemon program, I don't want the great majority of what
> that interface offers.

    So I can't persuade you from shifting focus from "When writing a
    Unix daemon program, I ...", to "When writing a cross-platform
    daemon/service, I ..."?

    Sidebar: this definition on the Qt page caught my attention:

        "A Windows service or Unix daemon (a "service"), 
         is a program that runs regardless of whether a 
         user is logged in or not."

    If you're vehemently against the notion of a cross-platform
    implementation that utilised Windows services; what about a
    Windows implementation that mimicked the Unix behaviour as 
    best it could?  That is, upon daemonisation, the Windows 
    process would change process group or whatever such that
    it would keep running after you log out, until killed.

    Not pretty, but it avoids all the problems of Unix-only.

> It misses a lot, again as a result of the mismatch in purpose. After
> setting up a QtService, I need to continue chattering with it to find
> out what's going on inside it, and to do things like change its state
> or log a message. The current PEP, on the other hand, doesn't have the
> model of managing a separate process; the daemon is the *current*
> program, so one can just do things like output or state changes as one
> normally would.
> 
> In short: It addresses a different problem to what I'm addressing with
> this PEP.

    Indeed it does, but that's 'cause I'm trying to change your focus
    from writing a Unix-only daemon to writing a cross-platform service
    that just happens to be implemented as a daemon on Unix and as a
    service on Windows ;-)

    Sure, the interface wouldn't be the same as if it were Unix-only,
    but that's what cross-platformness is all about, isn't it?


        Trent.