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

Ben Finney ben+python at benfinney.id.au
Wed Jan 28 03:48:46 CET 2009


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

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.

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.

-- 
 \         “If nature has made any one thing less susceptible than all |
  `\    others of exclusive property, it is the action of the thinking |
_o__)                          power called an idea” —Thomas Jefferson |
Ben Finney




More information about the Python-ideas mailing list