Re: [Qemu-devel] [RFC 3/5] nbd: Use aio_set_fd_handler2()

[Paolo Bonzini <pbonzini@redhat.com>]

Il 04/06/2014 14:37, Stefan Hajnoczi ha scritto:
> Why is this design cleaner?  Because NBD code doesn't have to worry
> about fd handlers.  It uses straightforward coroutine send/recv for
> socket I/O inside nbd_read_req() and nbd_write_resp().  It's easy to see
> that only one coroutine receives from the socket and that only one
> coroutine writes to the socket.

I don't understand how this would work without managing fd handlers.

- If you don't want to receive anything (because you reached the maximum 
queue depth), and the client sends something, the read handler will busy 
wait.  The current code solves it with can_read; you could do it by 
enabling or disabling the read handler as you need, but the idea is the 
same.

- If you're not sending anything, a socket that has a write handler will 
have POLLOUT continuously signaled and again you'd busy wait.  Since 
there is no can_write, nbd.c instead enables/disables the write handler 
around nbd_co_send_reply.

Removing can_read from the NBD server is simpler than Max's patch 2, so 
that's what I suggest.

The NBD server code uses a coroutine per request.  Using one coroutine 
per direction is nice, but doesn't avert the need to manage fd handlers.

Basically, it boils down to select(2) being level-triggered.  If it were 
edge-triggered, of course you could have other bugs but you probably 
could write network code without managing fd handlers.

Paolo