Re: [Libguestfs] [PATCH libnbd v2] examples: Include an example of integrating with the glib main loop.

On 7/17/19 8:00 AM, Richard W.M. Jones wrote: Looks good. If revents ever contains G_IO_ERR/G_IO_HUP, and if we ever add nbd_aio_notify_error(), we should inform the state machine about that fd problem. I've mentioned that idea before; I guess it is more of an optimization - we will probably notice the problem eventually if the client ever tries to issue another command or detects EOF while reading a response; but tying up the resource until the next client command vs. identifying the problem immediately may matter to some clients. Also, there may still be a possible race: It may be possible in rare situations that the libnbd state machine can send() the command AND see data ready to recv() (perhaps from a previous command still in flight), where it ends up read()ing until blocking and happens to get the server's reply to this command and fire off the callback, all prior to the nbd_aio_pread_callback() returning. If that ever happens, then buffers[i].rcookie will still be unset at the time the callback fires... ...such that we can hit this abort(). (Same for the write callback). But I don't know how likely that scenario is in practice, and don't see it as a reason to defer committing this patch as-is. I don't know if there is any way to rework the state machine to guarantee that a completion callback will not fire during the same aio_FOO_callback that registered the callback (that is, to guarantee that h->lock will be dropped and must be re-obtained prior to firing off a callback), but it's worth thinking about. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org