[Twisted-Python] LoopingCall at a non-idling reactor

[Glyph Lefkowitz]

On Sun, Jul 19, 2009 at 10:43 AM, Phil Mayers<p.mayers at imperial.ac.uk> wrote:

> Viewing the reactor as a device that emits a stream of events (timer
> ticks, socket reads, write requests etc.) the problem can be considered
> a QoS issue.  It's hard to see how the reactor could "know" how to do
> the right thing in all cases, absent a hinting mechanism from the
> application:
>
> queue = reactor.getDefaultQueue()
> subq = queue.newChild()
> subq.setMode('round-robin')
> subq.listenUDP(CONTROL, importantProto(), weight=10)
> subq.listenUDP(DATA, lessimportantProto(), weight=1)
>
> ...or something ;o) This isn't a serious suggestion obviously!

I know what you mean.  If you trawl through my really old blog posts
(I think the one I'm thinking of is on livejournal, but I can't find
it quickly) you'll see that I've thought about this before.  The two
main deterrents to changing the reactor to be a set of abstract
"events" placed into a queue by event handlers rather than a  loop
that just calls everything immediately are:

 1) it might be slower, since it's extra code being run for every event, and
 2) it's a massive amount of work to actually implement it :).

You could help out with #1 by implementing something and measuring it,
and you can help out with #2 by just implementing it and letting
someone else measure it :).