Draft PEP: Standard daemon process library]

On Wed, Jan 28, 2009 at 01:48:46PM +1100, Ben Finney wrote:
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?
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.
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.

Trent Nelson writes:
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.
This presupposes a point of view (“you”) that is someone *running* the program. For that point of view, this PEP is irrelevant. The audience for the current PEP, on the other hand, is a programmer *writing* such a program, who sees the API as addressing just one of the many and varied things their program needs to do.
How you got there (daemonising the current process) surely isn't as important as where you ended
I'm specifying an API, and trying to make it so people will want to use it for the purpose it's designed for. So yes, to the extent that “how you got there” includes programming to an API, I think it is very important in this context.
I could potentially be persuaded, but the “run an additional process as a service” model is definitely not a problem I need solved. Given that, I'm not likely to be a good champion for it. Meanwhile, the focus of this PEP *does* meet a need shared by many (“daemonise the current running program”), and I see value in keeping it focussed on that.
I noticed that too, and it didn't strike any chord with me. It seems targeted to people who want to write an MS Windows service that also happens to run on Unix. Those people doubtless exist, and deserve to find solutions to their challenges; but I'm not one of them.
If you're vehemently against the notion of a cross-platform implementation that utilised Windows services
You are arguing against a position I've never taken. I repeat: if someone else wants what you're describing, more power to them, and I don't intend to get in their way. But it's not going to be me that writes that PEP nor the implementation for it. -- \ “If you fell down yesterday, stand up today.” —_The Anatomy of | `\ Frustration_, H. G. Wells, 1936 | _o__) | Ben Finney

Trent Nelson writes:
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.
This presupposes a point of view (“you”) that is someone *running* the program. For that point of view, this PEP is irrelevant. The audience for the current PEP, on the other hand, is a programmer *writing* such a program, who sees the API as addressing just one of the many and varied things their program needs to do.
How you got there (daemonising the current process) surely isn't as important as where you ended
I'm specifying an API, and trying to make it so people will want to use it for the purpose it's designed for. So yes, to the extent that “how you got there” includes programming to an API, I think it is very important in this context.
I could potentially be persuaded, but the “run an additional process as a service” model is definitely not a problem I need solved. Given that, I'm not likely to be a good champion for it. Meanwhile, the focus of this PEP *does* meet a need shared by many (“daemonise the current running program”), and I see value in keeping it focussed on that.
I noticed that too, and it didn't strike any chord with me. It seems targeted to people who want to write an MS Windows service that also happens to run on Unix. Those people doubtless exist, and deserve to find solutions to their challenges; but I'm not one of them.
If you're vehemently against the notion of a cross-platform implementation that utilised Windows services
You are arguing against a position I've never taken. I repeat: if someone else wants what you're describing, more power to them, and I don't intend to get in their way. But it's not going to be me that writes that PEP nor the implementation for it. -- \ “If you fell down yesterday, stand up today.” —_The Anatomy of | `\ Frustration_, H. G. Wells, 1936 | _o__) | Ben Finney
participants (2)
-
Ben Finney
-
Trent Nelson