On Wed, Apr 10, 2019 at 09:53:17AM -0300, Jason Gunthorpe wrote: > 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. I can't ever imagine any sane definition in scenario of concurrent polling. Thanks > > Jason
Attachment:
signature.asc
Description: PGP signature
