Thanks a lot for this. I'll try it out on NT this weekend and it really
frightens me...
I'll post my experiences here when I'm done.

/ Paul


>> Does signal.signal work with this? I need to close the databases
>> properly.
>
> No. Last time I checked, signals only worked on Unix. And the
> win32process.TerminateProcess is a hard kill, i.e. any atexit
> functions you have registered will not be called. As far as I know,
> executing a soft kill of another process is currently beyond the reach
> of the win32all extensions.
>
> I just looked at Zope, and how it runs Medusa as an NT service.
> Surprisingly (to me, anyway), it uses the same
> CreateProcess/TerminateProcess approach. So there's no hope for you
> there.
>
> You could always google for 'win32serviceutil.ServiceFramework' and
> 'medusa' and see what turns up. But here are some other ideas.
>
> You could use a semaphore approach: a flag, external to both
> processes, to signal the change of state. Here's one simple way to do
> it: in the SvcStop method (which is run when the service is asked to
> stop), create a file in your app directory, named (for example),
> SHUTDOWN. Then have the service wait indefinitely while this file
> exists. As soon as it no longer exists, run the TerminateProcess
> command, and finish as usual. Meanwhile, in your 'backend' thread,
> check occasionally for the creation of the SHUTDOWN file. When it
> exists, that's your signal to close database connections. Close them,
> and then delete the SHUTDOWN file. Then the service can
> TerminateProcess, and you're done.
>
> If that's too medieval for you, you could open a pipe (via win32pipe)
> between the two processes, and send the database-shutdown signal that
> way. (If you don't own a copy of Mark Hammond's "Python Programming on
> Win32", it's definitely worth picking up if you are venturing into
> services, pipes and other Windows esoterica. Then again, Mark has been
> very gracious about sharing his expertise for free on
> comp.lang.python.)
>
> -- Graham
>
>
>
> _______________________________________________
> Quixote-users mailing list
> Quixote-users@mems-exchange.org
> http://mail.mems-exchange.org/mailman/listinfo/quixote-users