[ 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