This has been annoying me for at least 3 years now. I have no idea why the later check for `async_queued( &sock->read_q )` and `async_waiting( &sock->read_q )` doesn't catch this case, but this commit fixes it so idc too much.
Well, in general, one should understand the code, and know whether and why their patches are correct, before sending them...
Anyway, in this case the answer is simple: they're two different mechanisms. Poll asyncs and read asyncs are two different kinds of asyncs, corresponding to WSAPoll() and recv() respectively. As the comment describes (perhaps in a confusing manner), we want to resolve a recv() before signalling a poll, which is why we don't poll for POLLIN until an alerted recv is done being processed. But if there's no recv(), then that logic is irrelevant.
What it sounds like you're hitting is the case where the server has completed a poll and is trying to notify the client of that, so the async has been alerted, but the client, due to its suspension, has not yet received and processed the APC. And this patch is indeed the correct fix for that case.