On Wed, Apr 10, 2019 at 12:17:15AM +0000, Hefty, Sean wrote: > > > > > 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. Poll is always sort of racy like this.. Running poll on two threads for the same event is not well defined. Jason
