On Fri Feb 16 17:32:32 2024 +0000, Paul Gofman wrote:
I don't immediately see how this helps. It will remove the effect of the patch when async IO is going to be queued by the same thread which queued original async OP which will undesirably limit optimization scope. Also, in the view of I described, it would "fix" only the limited, not the most practically interesting aspect of the problem. I suppose the choice here is between:
- Go without such a limitation;
- Even if it looks like a practically least important case, don't touch
it turning the things into todo until we have some way to solve the problem in general (fwiw I tried thinking of how to solve that minor sync problem but didn't have immediate good ideas how that can be synchronized without introducing convoluted and perf impacting synchronization).
Maybe a bit more interesting thing in this direction would be to make the calling thread which is making server request process async queue itself always (one or another way, it should be technically possible), I think this would have a positive effect of not depending on the presence of threads in APC wait, but unfortunately that can only work if the async queuing thread is from the same process as the one which should process it. For the same process case that would solve the races though (and made this optimization more reliable by not depending on waiting in server_select threads).