On 05:44 pm, [email protected] wrote:
Thanks for both those suggestions.
I'll be taking a closer look at txLoadbabancer when I get time as it
looks
like it'll take care of a lot of my desired functionality out the box.
To get started tho I'll move my async routing decision call into the
protocol as suggested.
Is there any reason why the internal calls to buildProtocol shouldn't
be
wrapped in a maybeDeferred?
I'm not sure what you mean by "internal" here. I think you might mean
"calls to buildProtocol made by reactor implementations". It is a
mistake to take this perspective, though. If buildProtocol is allowed
to return a Deferred sometimes then *all* callers have to be prepared to
handle a Deferred (by using `maybeDeferred` or using some other
strategy).
This points to the reason *buildProtocol* can't be allowed to return a
Deferred. It is already defined as not returning a Deferred and
changing this definition would potentially break every call, both those
in reactor implementations and elsewhere (and there are plenty of other
places that call `buildProtocol`).
Whether there is any good reason we could not introduce a new interface
that is like `buildProtocol` but is also allowed to return a Deferred is
another (more interesting :) question. I can't think of any offhand.
The reactor would probably want to avoid monitoring new connections for
read or write events until this Deferred fired (but bonus points if it
still monitors it for connection lost and cancels the Deferred if this
happens before it fires). That's all relatively straightforward to
implement though, for someone sufficiently motivated.
Jean-Paul
_______________________________________________
Twisted-Python mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
