[ 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
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
