PEP idea - Daemon

[Georg Mischler]

Ryan Morillo wrote:

> Am I the only one that thinks we should add daemonization to the os
> module?
> [...]
> Probably name it background (for the windows types, easy to remember).
> What do ya'll think?


Some issues:

What is called a daemon in unix, should most often be implemented
as a system service on Windows. Those are two very different
approaches to the same problem, that can't easily be packed into
one module.

If you're just talking about sending processes to the background
in general, then there are still a few non-trivial differences.
On unix, you have to offer the choice of creating a new process
group or not, and probably some other things that I can't think
of right now.

On Windows, there are differences between subprocesses that are
supposed to open windows of their own or not, just to mention
the most obvious. There are a lot of other options when starting
processes, like their priority, resource inheritance strategies,
and so on. Note also that there is no obvious way to send an
*existing* process into the background, because fork() and exec()
are rolled into one single monster called CreateProcess(). You
normally have to make your choice outside of the new process and
then live with the results.

If you want to be thorough about that stuff, you might end up
with a module that contains a hell of a lot of platform specific
options. Maybe this isn't so much of a problem if you can figure
out reasonable defaults. Or you could offer several predefined
task specific configuration selections, that do the right thing
on each platform. If you factor in the subtle and not so subtle
differences between Windows versions, you might end up with quite
a puzzle...

Next you'll need to handle stdin/stdout/stderr in a reasonable
fashion. Each of them could be connected to a file, returned as a
pipe, or closed. And then you need to think about process
termination. Maybe you want your background job to become totally
independent, maybe you want to keep a handle, so you can query
its status and kill/suspend/resume it as necessary.

I don't think that much of that should go into the os module
directly, as the issues are just too diverse. I'm guessing that
you rather want a new module (eg. "process") that bundles all
those tasks into a class. If you're lucky, then you'll end up
with something that is actually useable, but still general enough
to attract a wider audience.

I have a group of fairly straightforward but not extremely clean
modules that do at least some of the above in a way that served
my purposes so far. If you're interested, then I could try to
strip them of external dependencies, and send them to you per
e-mail as a starting point (or as an example of what not to do in
case you shouldn't like them... ;).


-schorsch

-- 
Georg Mischler  --  simulations developer  --  schorsch at schorsch com
+schorsch.com+  --  Lighting Design Tools  --  http://www.schorsch.com/