[Me] > > I propose: > > We insist the child process can be created and continues to > > run for x seconds (where x~5).
[Jim] > I recommend against this strategy. It's too implicit and has > bitten us on > Unix in the past. The problem with the strategy if the > program starts very fast > and then dies, we don't restart it even though we should. > Similarly, if the > program starts very slowly, we don't recognize a startup > failure and keep > retrying even though we shouldn't. Thanks Jim. I agree with those concerns. Note that already we "do not recognise startup failure and keep retyring even though we shouldn't", and is exactly what I am trying to solve. > Is there some sort of IPC that can be used here? On Unix, we > use a reserved > exit code to indicate a startup failure and arrange for Zope > to exit with that. The Unix situation is a little different - if "runzope" itself has immediate startup failure, then everything immediately fails - ie, as far as Unix is concerned, the "service" itself failed. On Windows however, "runzope" is executed as a *child* of the service. If the child fatally fails, the service itself is still reporting success, and hopelessly attempting a restart. The service needs to know if the child fatally failed. This doesn't apply on Unix as "runzope" *is* the 'service', not the child of the service. By adding a layer around run.py, I believe we could arrange for these fatal errors to be handled with a special return code. Alternatively, if Zope itself never returns an error code of 1 (one), then we could use that - Python itself returns this for unhandled exceptions. That seems dangerous though. Can you offer some advice here? * Is an exit-code of 1 suitable for a fatal error? If so, this requires no changes to the child process. However, I assume it is not suitable. * Is a special exit code, generated by a wrapper to run.py (eg, run_svc.py) suitable? If so, what value do you recommend? * Should some Win32 specific, robust IPC mechanism be investigated? This would cut deeper into a run.py wrapper, and obviously is not a general solution. > On another note, I'd really prefer to work out a general facility that > can be used with any Python program, including both Zope 2 and Zope 3. The problem at the moment is that our facilities are *too* general - ie, without some coordination between the parent and child, the parent must guess. The simplest coordination does seem to be process exit code, but that seems fragile. But whatever coodination is chosen, any Python program that was willing to play the coordinate game could use it. The "simpler" this game to play, the more fragile the system is (ie, just using exit codes is simple, but fragile; using other IPC mechanisms could be made robust, but is not simple - especially not in a platform independent way.) Mark. _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )