[Web-SIG] daemon tools

[Rodrigo Senra]

[ Sidnei da Silva ]:
|The service, after being registered can be managed with standard tools
|present on the system:
|
|C:\src>net stop bthserv
# cut
|C:\src>net start bthserv
# cut
|C:\src>sc \\pena queryex bthserv
# cut
|C:\src>sc \\pena queryex xmlprov
# cut

And, I am sure you are aware of that, the service can also be managed
by Python through win32all:

<code>
    # random samples from a python service watchdog ;o)
    hscm = win32service.OpenSCManager(None,
                                      None,
                                      win32service.SC_MANAGER_ALL_ACCESS)

    hsvc = win32service.OpenService(hscm, 
                                    service, 
                                    win32service.SERVICE_ALL_ACCESS)
    status = win32service.QueryServiceStatus(hsvc)
    # code to test status and decide to restart it (or not) omitted
    win32service.StartService(hsvc,None)
</code>

|I would say that, thus, a service manager like 'zdaemon' it's not
|actually that useful on Windows *unless* it implements a Windows
|Service.

For symmetry's sake in Windows a Python service manager could simply
use SCManager API under the hood (through win32all) to get the job done,
still keeping a consistent cross-platform modus operandi.

| In fact, I could see it being used as both a 'standalone
|service manager'

Do you mean a wrapper for native SCManager services ?


|There's some stuff from zdaemon that would be useful though, and do
|not work on Windows today due to some over-unixism in zdaemon, like an
|interactive prompt and script runner as 'zopectl debug' and 'zopectl
|run', I'm sure those two don't need to know about 'fork' or signals.
|
|What I'm really interested in is in how the service would communicate
|with the program being controlled. This is the painful part, and where
|I think we need to work together to make sure it works on Windows and
|on *nix platforms. You can surely count on me to discuss that part.

One naive suggestion would be to wrap Unix signals and Windows Event
Objects under a single signaling abstraction. If what you meant by
"communicate" can be restricted to flag-waving (and *not* some general
data structure IPC), then these mechanisms should suffice.
At least, I can say that Windows (manual reset) Event Objects are simple,
robust (even in multi-threaded scenarios), and reasonably cross-platform
from within the Windows family, IMHO.

|As I mentioned on another thread, Zope uses 'signals' on *nix, and
|'named events' on Windows, by means of the 'Signals' package in Zope.
|We could possibly re-use that.

Great, just checked that out. I think that is the way to go.

Cheers,
Senra

-------------
Rodrigo Senra
GPr Sistemas 
http://www.gpr.com.br