Hi Stefan, Thank you for reviewing my code!
I tried to reach you on IRC. But somehow either you missed my message or I missed your reply. So I will reply by email instead. If we use qio_channel_set_aio_fd_handler to monitor G_IO_IN event, i.e. use vu_dispatch as the read handler, then we can re-use vu_message_read. And "removing the blocking recv from libvhost-user" isn't necessary because "the operation of poll() and ppoll() is not affected by the O_NONBLOCK flag" despite that we use qio_channel_set_blocking before calling qio_channel_set_aio_fd_handler to make recv non-blocking. Previously I needed to run customized vu_kick_cb as coroutines to call blk_co_readv/blk_co_writev directly. After taking Kevin's feedback on v4 into consideration, now I use aio_set_fd_handler to set a read handler for kick_fd and this read handler will then call vu_kick_cb. On Thu, Feb 20, 2020 at 1:58 AM Stefan Hajnoczi <stefa...@redhat.com> wrote: > > On Tue, Feb 18, 2020 at 01:07:06PM +0800, Coiby Xu wrote: > > v4: > > * add object properties in class_init > > * relocate vhost-user-blk-test > > * other changes including using SocketAddress, coding style, etc. > > Thanks! I think the vhost-user server code can be simplified if > libvhost-user uses the event loop for asynchronous socket I/O. Then > it's no longer necessary to duplicate vu_message_read() and > vu_kick_cb(). I've replied to Patch 1 and we can discuss on IRC if you > want to chat about it. > > I've also CCed Marc-André to see what he thinks about removing the > blocking recv from libvhost-user and instead using the event loop (just > like for eventfds). > > Stefan -- Best regards, Coiby
