x42005e1f commented on issue #50185: URL: https://github.com/apache/airflow/issues/50185#issuecomment-2967315728
> Actually, how about this [@x42005e1f](https://github.com/x42005e1f): If queues are also used for asynchronous code, the problem remains. Let's imagine that asynchronous code sent a request and then the event loop switched execution to another task that called the sync send code. Then the first response will be for the asynchronous code, and the synchronous code will wait forever for that response to be removed from the queue, which will never happen because execution will never switch back to the asynchronous code. This is now not a deadlock, but an eternal load on the processor. If the queues are only for synchronous code, then yes, that might solve the problem. However, in any case, I suggest removing `self._q_responses`, since such polls are almost always a bad thing. Just send a future (`concurrent.futures.Future`) along with the frame. Call `future.result()` in the sync send code, and let the producer put the response in the future via `future.set_result(response)`. Then the consumer will wake up and get their response from the future. -- 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: commits-unsubscr...@airflow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
