meejah

Hmm, yeah that's wrong. It actually should be using `txaio.create_future()`, probably? (Although, inside `autobahn.asyncio.*` we can often get away with using asyncio-specifics). If we keep the bare `Future()`, it should...

Yes, https://github.com/crossbario/autobahn-python/pull/748 may be "a" stop-gap solution, but we need some tests for this and also need to figure out the implications of not using the `txaio` stuff -- that...

I have a use-case question, too: does _anyone_ need a loop-per-`WebSocket*` factory, or is the ability to change "the" loop sufficient? `txaio` is basically a lowest-common-denominator library between asyncio and...

Yes, we _can_ use asyncio-only APIs inside this asyncio-specific package. However, txaio has its own concept of "the" event loop and this stuff bypasses all that -- so needs some...

What I think we should do is: remove the `loop=` kwarg entirely, and fix this code so it uses the `txaio`-configured event-loop (if available) or the default event loop otherwise...

Well, we can't have `txaio.create_future(loop=..)` because Twisted doesn't support that -- this is why `txaio` has _one_ event-loop configured globally. But, I guess you're suggesting some sort of intermediate object...

I agree this class is breaking the implied contract from the `loop=` kwarg. It's _also_ breaking the contract of "I set up an alternate event-loop in `txaio`". BOTH of the...

I hadn't really considered a "thread-local" txaio loop (which obviously would just be "the" reactor for Twisted). I wonder: would this cover @soulmerge's use-cases? Twisted I believe realizes the mistake...

Things that use `txaio.config.loop` right now are: - `txaio.create_future` - `txaio.as_future` - `txaio.call_later` - `txaio.make_batched_timer` (The above for the asyncio side). For Twisted, it's a subset of that -- just...

In addition to the above, the web-socket base protocol uses `make_batched_timer` to reduce the number of timer objects we make when running with lots of connections. Currently there is one...