-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Description
I see in 6.2 beta that the IOLoop constructor is deprecated, and that migration docs are forthcoming. I wanted to report how we've been using one of the deprecated patterns as an example of something that might need migration.
We have a pattern of using tornado to handle some background IO in threads, that looks like:
from tornado.ioloop import IOLoop
class Background(Thread):
def __init__(self):
self.io_loop = IOLoop(make_current=False)
def run(self):
self.io_loop.start()
def stop(self):
self.io_loop.add_callback(self.io_loop.stop)This pattern of creating the loop and talking to it before it starts is super useful. But the code as-is has started failing with the 6.2 beta (I'm not sure if the breakage is intentional or not), and I see that calling IOLoop() constructor directly is deprecated, which I understand given its relationship to the deprecated asyncio.get_event_loop().
Now, I've found that the following code works, if I explicitly choose the AsyncIOLoop implementation:
from tornado.platform.asyncio import AsyncIOLoop
class Background(Thread):
def __init__(self):
self.io_loop = AsyncIOLoop()
def run(self):
self.io_loop.start()
def stop(self):
self.io_loop.add_callback(self.io_loop.stop)This makes sense to me, because AsyncIOLoop explicitly calls asyncio.new_event_loop and doesn't rely on any globals like get/set_event_loop. Is this a reasonable approach? Or is creating/accessing any tornado IOLoop while the asyncio loop is not running going to be unsupported, or at least discouraged?
Explicitly creating / having a handle on the event loop is easy enough with asyncio, but if we can't get a handle on the tornado IOLoop object until asyncio is running in the background thread, that's going to be a pain.