Really appreciate it! Looking forward to getting it merged into mainline! By the way, what time is it now in your city? ;-) Carter > 2020年2月15日 下午2:01，Jens Axboe <axboe@xxxxxxxxx> 写道： > > On 2/14/20 6:27 PM, Jens Axboe wrote: >> On 2/14/20 6:25 PM, Carter Li 李通洲 wrote: >>> There are at least 2 benefits over POLL->READ >>> >>> 1. Reduce a little complexity of user code, and save lots of sqes. >>> 2. Better performance. Users can’t if an operation will block without >>> issuing an extra O_NONBLOCK syscall, which ends up with always using >>> POLL->READ link. If it’s handled by kernel, we may only poll when >>> we know it’s needed. >> >> Exactly, it'll enable the app to do read/recv or write/send without >> having to worry about anything, and it'll be as efficient as having >> it linked to a poll command. > > Couldn't help myself... The below is the general direction, but not > done by any stretch of the imagination. There are a few hacks in there. > But, in short, it does allow eg send/recv to behave in an async manner > without needing the thread offload. Tested it with the test/send_recv > and test/send_recvmsg test apps, and it works there. There seems to be > some weird issue with eg test/socket-rw, not sure what that is yet. > > Just wanted to throw it out there. It's essentially the same as the > linked poll, except it's just done internally. >
