> On 18 Jul 2016, at 09:15, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: > >> On Jul 16, 2016, at 06:01, Amber Hawkie Brown <hawk...@atleastfornow.net> >> wrote: >> >> 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. > > Which factories need this reference given? Some need a clock, for e.g. > timeouts, but then... that's OK, give them a clock. The fact that a > parameter must sometimes be passed to two different places doesn't mean we > shouldn't make it a parameter...
Yes, but it's a very big footgun. If we are using a custom reactor, we must pass it at every level of the stack, when the information can easily be got from other sources. > Possibly the problem here is that 'doStart' and 'doStop' ought to receive the > reactor passed to them as well. And maybe something else, too, for that > matter, like an address, or an endpoint - that interface has always been a > bit annoyingly narrow. But a concrete use-case would help here. My use case is making it easier to write things that require the reactor not having to be given absolutely everywhere -- it's very very inpenetrable to look at every interface and see if it has a reactor parameter. > >> 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?) > > This use-case doesn't make any sense, because if you want to have a GUI you > need to use a GUI reactor for everything; the reference passed is the running > reactor. > Different reactors in threads (e.g. gilectomy, STM). >> -- 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. > > Where did idnar raise this problem? I am still not clear on exactly what > we're talking about. IRC, like I mentioned :) > > -glyph > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
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
