Andy Pan
Andy Pan
> it seems a new call to write while a read is already possible should not trigger a new event until after the old event has been read by the...
> > To sum up, before this PR, we use `eventfd` in LT mode and we need to perform a `read(2)` for every wakeup event and this extra system call...
What's your main concern here? I'm still not quite sure.
> The man page for epoll_wait specifically says this PR is not correct, but the kernel implementation may allow it. Do we trust that the linux kernel developers will never...
Maybe this could make things more interesting: https://lwn.net/Articles/865400/
> Alright, yeah, that email from Linus stating this this PR relies on a kernel bug that probably won't get fixed ([lwn.net/ml/linux-kernel/CAHk-=witY33b-vqqp=ApqyoFDpx9p+n4PwG9N-TvF8bq7-tsHw@mail.gmail.com](https://lwn.net/ml/linux-kernel/CAHk-=witY33b-vqqp=ApqyoFDpx9p+n4PwG9N-TvF8bq7-tsHw@mail.gmail.com/)) is probably compelling Well, it is shocking to...
> > Yes, we often do that when working with sockets, and that's legit. > > Note that this stated usage is still wrong (per the documentation and implementation), but...
> If you do read until EAGAIN, it is correct, but wastes a syscall every time you go to call `read` (as you could have used LT instead, and called...
So, what are we going to do with this PR? Does it still seem worth going through for `libuv`?
Huh, a few confusing test failures surface.