gopidesupavan commented on issue #63913:
URL: https://github.com/apache/airflow/issues/63913#issuecomment-4096921610

   > > 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](https://github.com/apache/airflow/pull/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 [add
 ed](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 option 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. In any case, we can assume that Option B 
has already been rejected, and we should favor the approaches that are already 
being used to solve similar issues.
   
   Thanks @x42005e1f for adding your inputs, could you elaborate what other 
options in favour your referring , i am happy to give it a try and see how it 
works..


-- 
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]

Reply via email to