x42005e1f commented on issue #63913: URL: https://github.com/apache/airflow/issues/63913#issuecomment-4088122240
> Replace the global `_lock` in `asend()` with a per-request `Future` pattern. Write requests without holding a lock, tag each with a request ID, and dispatch responses to the correct `Future` based on the ID. This was suggested in the discussion on [#50185](https://github.com/apache/airflow/issues/50185) by [@x42005e1f](https://github.com/x42005e1f). Later, [I suggested using a `ThreadPoolExecutor`](https://github.com/apache/airflow/pull/51279#issuecomment-2934712813) (with `max_workers=1` implied), which would serialize all requests without any synchronization issues. But my words had no effect. In #51699, the old communication was rewritten using asyncio streams (as I assume, to be more "pure async"; however, the worker threads did not go anywhere, they just became [implicit on the `asgiref.sync` side](https://github.com/django/asgiref/blob/f41c0c77cc9502dae68e2b8cb84a5171e9e687f7/asgiref/sync.py#L401-L402), so I find [this motivation](https://github.com/apache/airflow/pull/51279#issuecomment-2934389302) a bit strange). Subsequently, the `greenback`, which I had [discussed](https://github.com/apache/airflow/issues/50185#issuecomment-2912697685) and [warned could lead to hard-to-detect bugs](https://github.com/apache/airflow/issues/50185#issuecomment-2917802668), was even [added](https://github.com/apache/airflow/pull/55799) (in fact, it is a workaround, not a solution). So now the implementation is a mess that remains unfinished (issues with `AsyncToSync` and related PRs are still open). Probably, a more suitable solution at this point would be to continue mirroring methods/properties and, in difficult cases, rely on that same greenback. It is a pretty rough approach, since users will still have to find unaccounted-for cases, but... oh well. -- 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]
