> On 15 Jul 2016, at 23:06, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: > >> >> On Jul 15, 2016, at 6:02 AM, Amber Hawkie Brown <hawk...@atleastfornow.net> >> wrote: >> >> (disclaimer: this is after several hours on an aeroplane, this may all be >> nonsense) >> >> So, I'm currently looking into adding some features to twisted.web -- >> something that historically hasn't had the best support for pluggable >> reactors, and which requires levels and levels of monkeypatching (see the >> top level of >> https://github.com/twisted/twisted/compare/trunk...deferreds-in-resrender-3711 >> ). So, I was thinking, what if we made a new way for things to get their >> reactor, rather than extending all these concrete implementations everywhere? >> >> Currently, you'd pass a reactor instance through to protocols by making the >> factory understand it, and the protocol calling self.factory._reactor or >> whatever. I never thought this was a supremely helpful or useful interface >> -- especially for one-shot classes -- so what if instead we made a new >> IProtocol-extending interface, which signals to tcp.Port/etc that the >> protocol, once created, should have a reactor set on it (maybe through some >> "setConnectingReactor" or something). This would mean that the factory >> doesn't know about the reactor in most cases (with things like HTTPFactory >> doing logging as an exception) -- but we could also have an >> IClient/ServerFactoryWithReactor, that Endpoints (which needs to know about >> the reactor, and which reactor it is listening on) can then check for and >> call a similar function, telling the Factory what reactor it is actually >> running under. >> >> This, I think, would reduce a bunch of duplicate code in __init__s of >> factories, and could be implemented in the base class of Protocol or >> ServerFactory, possibly. What do people think? > > > First off, I think a clearer articulation of the problem would be helpful :). > Is it "I don't want to take parameters in __init__"? Or "I don't want to > have duplicated code to grab the global reactor everywhere, but I still want > to grab the global reactor everywhere"? Is it "most factories don't need the > reactor except to hand it to their protocols, therefore they shouldn't have > to have code to deal with it at all"? > > I definitely don't think we should address any of these issues with > 'setConnectedReactor'. This is using a side-effect rather than just > constructing the object with the things that it needs. We also shouldn't do > it with a base class. Depending even more on inheritance would be movement > in the wrong direction. > > If we want to address the issue of duplicated code in constructors, how about > something like a @reactorParameter(name='reactor') decorator, which does the > grab-the-current-global-reactor-if-it's-not-passed thing? A better pattern > is 'just pass in the reactor', of course. > > Or, perhaps what you want is this 7-year-old ticket? :) > https://twistedmatrix.com/trac/ticket/3205 > > -glyph
Yes, that ticket is almost what I want! That is a much better solution for Protocols. However, Factories still need the reactor given, and it seems really silly and very hard to explain why you both would need to create a Factory with a reference to a reactor, and then call reactor.listenTCP/endpoint.connect/listen, also with a reactor. I feel like one of these should really be able to tell the other. This also doesn't fit the problem idnar raised on IRC -- that the reactor serving the connections may not be the one that the protocol wants to use, for whatever reason (gui reactor and a not gui reactor?) -- I can't say if #3205 has the same problems, but I believe it does. I guess then that's up to the protocol, but I kind of would like if all protocols had one consistent place for "this is the reactor I should schedule things on" -- and transport.reactor does not seem to be it, because that's still got the problem that idnar has raised. - Amber
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
