Assertion errors causing exceptions that kill Jupyter kernels about tornado HOT 3 OPEN

OK, so it looks like the canonical issue for this on the jupyter side is jupyter/notebook#6721. As of this writing, upgrading the ipyflow package and/or downgrading jupyter_client are reported to fix the problem.

My understanding is that the jupyter project has kind of gotten themselves stuck in a strange place. Originally they used Tornado and they called the IOLoop reentrantly (e.g. calling IOLoop.run_sync from within a callback running on the IOLoop thread). This is surprising to me and has never been supported, but apparently it worked for the original Tornado IOLoop. Then Tornado adopted asyncio, which has stricter protections against reentrant use of the IOLoop. Jupyter responded by adopting nest_asyncio, which does some hacks to bypass those protections. This has its own compatibility problems as python and asyncio have evolved, so Jupyter recently moved away from nest_asyncio to start using a separate thread. This is the correct long-term solution IMHO, but introducing threading is tricky and bugs like this may occur.

As far as I can tell there's nothing Tornado could change to fix this; it's going to have to come from the Jupyter side. I'm going to leave this issue open to direct people to jupyter/notebook#6721

from tornado.

The only time I've seen this assertion fire was in #2871 where it was caused by incorrect usage of threads. You must not call any Tornado methods except IOLoop.add_callback from any thread other than the event loop thread. If you're sure you're not doing anything with threads, then I'd need more information about what exactly you are doing to provide any guidance here.

from tornado.

I've run into the same issue. There's a thread here that might give more info: https://discourse.jupyter.org/t/jupyter-notebook-zmq-message-arrived-on-closed-channel-error/17869/5

from tornado.