> On Oct 10, 2016, at 9:41 AM, Daniel Sutcliffe <dan...@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
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
