[Twisted-Python] Is there a recommended way for a Service to request Application stop?
Glyph Lefkowitz
glyph at twistedmatrix.com
Mon Oct 10 15:51:24 MDT 2016
> On Oct 10, 2016, at 9:41 AM, Daniel Sutcliffe <dansut at gmail.com> wrote:
>
> I have a hierarchy of Services some of which is MultiService and other
> parts are my own implementations of IServiceCollection - in some
> situations the a child Service may want to 'suggest' that the
> Application's job is done (error, or simply task completed) and I'm
> looking for some sort of standardized way to pass this info upstream.
> The idea being that I may using my implemented Services in a variety
> of Applications.
>
> In this type of situation, is it the general intention a child Service
> would use the Application directly, such that potential StopService()s
> could bubble down? Or is there a normal pattern here to have messages
> bubble up through the Services hierarchy? I'm not seeing anything like
> this in the examples I've found or looking through the sources, but
> I'm probably missing something.
Services are just things that can be started and stopped. Application is just a top-level object that associates a thing-to-start with a few bits of global process-level state, like logging and pidfile settings.
Therefore, the Service hierarchy abstraction is a poor fit for some code that needs to do some work and then exit; it's designed for long-running tools which can be started and stopped on demand. For example, what happens if two Service objects think that the Application's job is "done"?
If you want to exit a process, calling `stop` on the reactor is generally the right way to go.
But: talking about this in such vague, abstract terms is unlikely to be helpful. What, concretely, are you actually trying to do with the "Services in a variety of Applications"?
-glyph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20161010/304210d3/attachment-0002.html>
More information about the Twisted-Python
mailing list