On 8/15/20 8:20 PM, Jens Axboe wrote: > On 8/15/20 8:14 PM, Josef wrote: >>>> Hence it'd be helpful if you explain what your expectations are of >>>> the program, and how that differs from how it behaves >> >> yeah that's true, I'm sorry about that. >> >>>> Are you sure your code is correct? I haven't looked too closely, but it >>>> doesn't look very solid. There's no error checking, and you seem to be >>>> setting up two rings (one overwriting the other). FWIW, I get the same >>>> behavior on 5.7-stable and the above branch, except that the 5.7 hangs >>>> on exit due to the other bug you found and that is fixed in the 5.9 >>>> branch. >>>> >>> >>> Took a closer look, and made a few tweaks. Got rid of the extra links >>> and the nop, and I added a poll+read resubmit when a read completes. >>> Not sure how your program could work without that, if you expect it >>> to continue to echo out what is written on the connection? Also killed >>> that extra ring init. BTW, something I think you're aware of, but wanted to bring up explicitly - if IORING_FEAT_FAST_POLL is available in the ring features, then you generally don't want/need to link potentially blocking requests on pollable files with a poll in front. io_uring will do this internally, and save you an sqe and completion event for each of these types of requests. Your test case is a perfect example of that, neither the accept nor the socket read would need a poll linked in front of them, as they are both pollable file types and will not trigger use of an async thread to wait for the event. Instead an internal poll is armed which will trigger the issue of that request, when the socket is ready. -- Jens Axboe
