Hi Pieter, On Sun, Apr 15, 2018 at 10:55:34PM +0200, PiBa-NL wrote: > Hi Willy, > > Sending a patch proposal after like 40 hours of looking through what happens > and what event we might be missing, im now changing +-40 lines of code.. And > actually not 'really' changing the events requested.. But rather kinda > bringing the old 'previous state' comparison back.. > > Lemme know if its okay like this, you would like the new variable to be > renamed, the if/then/else restructured or just don't like it at all ;). > In the last case please do give a hint about what you would like instead :).
Well to be clear, I'm pretty sure we're hiding the dust under the carpet here, even if it fixes the problem in your case. What I need to do is to actually understand why we end up in this situation. Your patch should actually let me figure what conditions can lead to the different code paths before and after the patch. At this point I really feel that having two distinct bits for polled/read and polled/write is wrong, but I can't explain why yet, it's just a feeling. However it's very likely that in some cases we remove the bit in the polled_mask too early while we believe it's still there, which could explain why your fix gets rid of it. Given that kqueue uses two different events for reads and writes, it could also explain why this issue only affects it and not the other ones. I think that the change your code introduces is a different sequence when R and W are registered together but one first then the other one. Probably that the current code incorrectly detects this. I'll check with Olivier, he has enough FreeBSD machines to test on and knows this area well enough. Thanks a lot for your investigations! Willy
