> > > > An issue showed up when integrating rsockets into Java: the behavior > > > > of the socket poll() call differs from the RDMA poll() operation. > > > > Specifically, socket poll() releases all waiting threads, where the > > > > RDMA stack releases one. For example, see wake_up_interruptible() > > > > when writing a CQ event here: > > > > > > This is just a bug, it should be fixed. > > > > A bug fix patch would be trivial, but this would change the behavior > > that I think has existed since day 1. Are people okay with that? > > No app could rely on this difference for correctness To follow up on this... I found documentation that indicated wake_up_interruptible() wakes up all threads, and that appears to be the case. Thread 1 is simply returning to user space and reading the event before the thread 2 can run. Thread 2 runs, finds the event queue empty, and with no events to report, I suspect that causes poll() to resume. If I pause thread 1 before reading the event queue, both threads return from the kernel. I tried to walk through the tcp poll() flow, and I *think* the general behavior would be the same. I haven't tested this however. I now believe the issues are specific to how rsocket maps rpoll() to poll(), and the mapping of events (i.e. POLLOUT maps to POLLIN). Basically rsockets needs all threads blocked in poll() to return from the kernel, in case the real event they were monitoring has occurred. - Sean
