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. >> > > sorry my bad.. I will ensure that the code is more self-explanatory > and better error checking next time. It was supposed to reproduce the > read event problem in C since I had the same issue in netty, basically > the idea was just to read the event once to keep it more simple No worries, it's still better to get something than nothing! And I don't care about the error handling, but I think providing an explanation of expectations and reality from the point of view of the reporter is a key element in a bug report. It just makes sure that the problem description is as clear as it can be. >> After that, I made the following tweak to return short reads when >> the the file is non-blocking. Then it seems to work as expected >> for me > > yeah I tested and it works in netty & my bad C example, thank you for > the super fast fix :) Great, thanks! -- Jens Axboe
