Phillip J. Eby wrote:
> At 02:17 PM 6/25/2007 -0700, Robert Brewer wrote:
> > Phillip J. Eby wrote:
> > > At 01:51 PM 6/25/2007 -0700, Robert Brewer
wrote:
> > > For example, if an error occurs, isn't that
an indication that the
> > > component is broken? Masking the failure
just makes it
> > > less likely the component will get fixed in a
timely manner.
> >
> > Yes, the component is broken. However, at runtime,
breakage in a
> > CherryPy component shouldn't keep a Quixote
component from, say,
> > correctly freeing its DB connections.
>
> In theory that makes sense, but in practice if you're
using
> priorities because there is a dependency sequence
involved, then you
> now have a new problem, since a component you're
relying on having
> started or stopped first, is now violating its
invariants.
>
> I'm not opposed to logging or catching errors, but I am
opposed (in
> the absence of more specific evidence) to allowing
callbacks to
> propagate unhandled exceptions in the spec, or
encouraging event
> senders to make heroic efforts in the face of unhandled
> exceptions. Trying to recover from brokenness is
generally not very
> likely to result in *less* breaking, IMO.
I agree with that in the general case, and specifically for
site
startup, which is prone to dependencies and priorities. The
specific
case where I feel we need different behavior is when trying
to shut down
a site, which rarely involves dependencies and priorities,
but can often
lead to increasing damage if an early component errors and
remaining
resource cleanup routines are not allowed to run. Maybe we
should just
special-case the latter and let the rest fail fast.
> > > Meanwhile, if you get a start call, you must
be starting,
> > > right? So why worry about the state? It'd
be simpler to
> > > just use "before/during/after"
messages the way Twisted does.
> > > Your "block" example could be
replaced by waiting for the "after"
> > > message of the desired state, for example.
> >
> > That's a possible way to go. My intention was to
support both
> > 1) examination of the state by external components
(for
> > operations other than 'block'--progress meters
spring to mind)
> > and 2) restrict some state transitions if
necessary; for example,
> > make bus.start() do nothing (or block) unless the
state is
"STOPPED".
>
> Progress meters can be handled by callbacks, too.
With sufficent complexity, yes.
> As for the restrictions, who benefits? ISTM that
components need
> to manage their own lifecycles anyway and should be
idempotent
> with respect to repeated transitions.
Good point. Requiring idempotent operations would allow fun
sequences
like:
>>> bus.exit()
>>> bus.exit()
>>> help!
SyntaxError: invalid syntax
>>> os.unlink(errant_lock_file)
>>> bus.exit()
...process finally exits...
That would also allow someone to call bus.exit() in the
middle of
another thread executing bus.start()...if each component
manages its own
state, that would minimize shutdown errors like closing DB
connections
that were never opened.
Hmm...
Robert Brewer
System Architect
Amor Ministries
fumanchu amor.org
_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com
|
