x42005e1f commented on issue #50185: URL: https://github.com/apache/airflow/issues/50185#issuecomment-2917802668
Also note that this greenlet approach requires interrupt support - synchronous functions that contain such sync-or-async calls at least indirectly (via subcalls) must be aware that they can be interrupted and called again (i.e. they must be coroutine-safe). Otherwise, the effect will be like a multithreaded function call, but with cooperative multitasking, the possibility of deadlocks when using primitives from the threading module, and broken `threading.local`. If it is possible to write asynchronous versions for functions that use `SUPERVISOR_COMMS.lock` with little effort, it is better to do so. If not, the above approach can be considered as a temporary or permanent solution (depending on whether you are willing to keep an eye on coroutine-safety). Note that selecting the first option (separate asynchronous functions) requires that there be such functions for each use case of `SUPERVISOR_COMMS.lock` via the asynchronous API. If an asynchronous function calls at least one synchronous function that directly or indirectly uses `SUPERVISOR_COMMS.lock`, this immediately risks deadlocks, possibly even hard-to-detect ones. This caveat is only true for calls within the same thread. If `SUPERVISOR_COMMS.lock` is used synchronously in a separate thread (e.g. via `sync_to_async()`), everything is fine. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
