Ben Finney writes:
[C]ompare the latest version of this PEP [...].
I'm assuming the one posted on 1/29 in <87iqnywsx2.fsf@benfinney.id.au>, or fairly close to that.
This might because the PEP isn't communicating very well. Does the section "A daemon is not a service" help to explain the fundamental difference between the model suggested by Trent, versus the model in the PEP?
That is quite clear, and you've said "daemonize-me != start-a- service" in discussion here. However, you've also said that "daemon != service" (including in the title of that section!), which clearly is mostly false when those terms are referring to the processes that are running in the background. I think that focusing on the distinction between "*becoming* a daemon" and "*starting* a service" is distracting. The point being that *becoming* a well-behaved service surely requires becoming a well- behaved background process. The real issue is not starting a separate process (just don't provide a way to do it), but rather it is that it also requires all the communication setup as well, which is out-of- scope for a daemonization PEP on any platform (apart from closing file descriptors, which is specific to the fork(2) implementation of process creation). To prevent the misinterpretation I made, I would phrase that title "A Service is Not Just a Daemon", implying "this PEP is not a full-service PEP".<wink> BTW, IMO you can delete the sentence "It is the opinion of this PEP's author that combining the two disparate systems of behaviour under a single API would be contrary to the focus of this PEP." from the PEP. It's redundant.
Meanwhile, I and others have a need for a simple, standardised, one-obvious-way "daemonise the current program" library, *entirely distinct from* any of ther extra baggage that comes with a "spawn a separate process that I can then communicate with through channels" API. I intend to satisfy that with this PEP.
Well, that's what I thought was in question here. It seems to me that there are likely to be additional aspects to "daemonize me" for Mac OS X and Windows, but that the basic start-reload-stop methods should probably apply. I'm not familiar enough with the process of daemonization on Mac OS X (Bill mentioned interaction with launchd) or Windows to help at reasonable expense, but I certainly hope that those who are will review to see if a similar API might be useful to them. Unfortunately there doesn't seem to be that much common ground among the advocates, though. Steve