> On Jul 18, 2016, at 12:53 AM, Amber Hawkie Brown <hawk...@atleastfornow.net> > wrote: > > >> 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.
How is passing a reactor parameter a 'footgun'? What is the misuse you anticipate that will cause people to habitually use incorrectly? >> 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. You have to look at every interface to see what other parameters it has though. So I don't see how it is impenetrable. In fact it's required :). >>> 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). In that case we'd need an API for getting the reactor for the current thread (ideally when the thread was started). In that case it still wouldn't make much sense to pass a different one to a Protocol and a Factory. >>> -- 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 :) It would be good to get a write-up of the whole problem first, then. Making new functions that accept parameters is not a "problem" :). -glyph _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
