get_running_executor a modern alternative
Summary: In the long term I want to force all usage of get_executor to require that the call comes from a running asyncio eventloop as its safer/saner than allowing the default un-running loop to be used since it may never actually run. Until then I have created get_running_executor that I can use in various places. When get_running_executor(True) is used everywhere we can codemod it back to get_executor() and have asyncio.get_running_loop() used exclusively. A folly::IOBuf can be built around a Python Buffer. It supports three ways to ask python to cleanup that buffer. 1. If it has the GIL just decref the buffer 2. else if it has a Python Executor it can schedule the cleanup 3. it can rely on some cPython magic called "Py_AddPendingCall" thrift-py3 deserialize wraps a python buffer in a IOBuf, but since ownership is not handed off to C++ it has the GIL when we destroy the IOBUF so it doesn't need an Executor. IOBuf calls folly.executor.get_executor() which will create a AsyncioExecutor and bind it to the default eventloop. So using deserialize right before a python fork, would cause a ABORT in the child since the AsyncioExecutor would try to drive() itself during its destruction. The asyncio default eventloop is considered a bad thing, new interfaces like asyncio.run() does not rely on a default loop but creating its own. To insure we only ever use the eventloop from a running loop, use get_running_loop. Reviewed By: sdunster Differential Revision: D26794162 fbshipit-source-id: 8e7e53c453c9ccff7e81f02e0692c8bebad70edd
Showing
Please register or sign in to comment