Move `Signals` back from `ZServer` to `Zope`?

[d-maurer]

I am currently porting a Plone application to Plone5.2/Zope 4 and noticed a problem with its use of Signals.SignalHandler.registerHandler.

Formerly, Zope itself registered handlers for SIGINT and SIGTERM. When an application registered its own handlers, the default behaviour (stop the process) was activated after the application specific handlers. Nowadays, Zope no longer registers its own handlers (likely because Signals was moved to ZServer). When an application registers a signal handler for SIGINT or SIGTERM, the process no longer stops (unless the handler does the stopping).

Like webdav, Signals is not really ZServer dependent (i have the impression, that things not immediately fundamental to Zope had a tendency to get moved to ZServer). Should we move back Signals from ZServer to Zope and let Zope register again default signal handlers for SIGINT and SIGTERM?

[ale-rt]

@d-maurer nowadays Python has a built-in signal library and I think that the old Signals module should just go away. I already replaced succesfully registerHandler from the old Signals module with signal.signal in this PR https://github.com/plone/plone.app.robotframework/pull/98/files.

I hope this helps!

[d-maurer]

Alessandro Pisa wrote at 2019-9-12 00:19 -0700:

@d-maurer nowadays Python has a built-in signal library and I think that the old Signals module should just go away. I already replaced succesfully registerHandler from the old Signals module with signal.signal in this PR https://github.com/plone/plone.app.robotframework/pull/98/files.

I hope this helps!

Signals is using Python's signal (at least under "posix") and provides an additional feature: handler chains. This feature is nice as it facilitates modularity: a subcomponent can register its own signal handlers and has no need to know about other subcomponents. With Python's elementary signal, there is a single global signal handler for each signal and something must do the coordination (that is what Signals does).

[ale-rt]

Ok! Thanks for sharing :) Ignore my comment please!

[pbauer]

I frequently used the option to use kill -s SIGUSR1 <PID_OF_ZOPE_INSTANCE> to get a stacktrace of a running instance without halting it. I'm not sure if that's directly related but if it would re-add this I'm 👍

[icemac]

I never used the Signals package. If it is useful, I could be resurrected from the ZServer grave.

If possible I'd prefer to have it in a separate package (outside) Zope and Zope not depending on it: Each additional module in the core increases the maintenance burden; especially if it is only needed for very specific use cases.

[d-maurer]

Michael Howitz wrote at 2019-9-13 01:24 -0700:

I never used the Signals package. If it is useful, I could be resurrected from the ZServer grave.

If possible I'd prefer to have it in a separate package (outside) Zope and Zope not depending on it: Each additional module in the core increases the maintenance burden; especially if it is only needed for very specific use cases.

"Signals" is small -- however, it tries to hide some differences between Unix and Windows regarding signal handling (and, I, e.g. cannot test the Windows part).

"Signals" will be significantly more difficult to use, if Zope does not use it itself -- to ensure that its signal behaviour is the last one activated. The reason for this: handler for a signal are activated in reverse reqistration order; Zope's signal handlers will typically terminate the process - which means that they must be registered before any other handler for the signal.

While is is possible to enfore an order in which components are activated, it is not easy/straightforward. Therefore, Zope should register its handlers before any application specific code is activated.

[icemac]

So it is not in addition to the Zope features but requires at least a bit of interaction. But this should not hinder putting Signals into a separate package. (Having it there does not need to mean it can be used elsewhere but instead that Zope can live without it.)