runtime_client is holding the GIL (Global Interpreter Lock) while it is polling for the runtime/invocation/next invocation, which is meant to be an async I/O operation.
According to the Python extension docs on Initialization, Finalization, and Threads, any blocking I/O should release the lock explicitly to allow other code to continue. This is especially true for extensions where developers (us, in this case) should manage releasing/reacquiring the lock.
Without the lock, even the simplest operations could cause problems in a multi-threaded program: for example, when two threads simultaneously increment the reference count of the same object, the reference count could end up being incremented only once instead of twice.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Notes
runtime_clientis holding the GIL (Global Interpreter Lock) while it is polling for theruntime/invocation/nextinvocation, which is meant to be an async I/O operation.According to the Python extension docs on Initialization, Finalization, and Threads, any blocking I/O should release the lock explicitly to allow other code to continue. This is especially true for extensions where developers (us, in this case) should manage releasing/reacquiring the lock.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.