On 7/30/19 5:54 AM, Richard W.M. Jones wrote:
On Tue, Jul 30, 2019 at 11:51:40AM +0100, Richard W.M. Jones wrote:
Previously discussed here: https://www.redhat.com/archives/libguestfs/2019-July/msg00213.html
It turns out that deferring callbacks is a PITA. (It would be a bit easier if C has closures.) However by rewriting the example we can avoid the need to use the cookie at all and make it run a bit more efficiently, so let's do that instead.
I was going to say also:
The callbacks pass the command cookie back to the caller, and are thus all potentially racy. There seem to be two possibilities here: (1) Drop the cookie parameter entirely. (2) Document the possible race so that users don't use the cookie inappropritely.
I think I favour option (1).
We already have option (2) to some extent; libnbd.pod states: The completion callback will be invoked with C<cookie> set to the same value returned by the original API such as C<nbd_aio_pread_callback> (in rare cases, it is possible that the completion callback may fire before the original API has returned). But I also favor option (1); my recent changes to nbdkit to use auto-retire also managed to get rid of the need to rely on the cookie argument. The cookie is still important for clients not using auto-retire, but by getting rid of the cookie parameter to the completion callback, we are forcing the client to do their own mapping of their void* parameter to determine which command is being completed - but that turns out to be the most efficient anyways (both nbdkit and your glib example got that that point without too much difficulty). It's another API/ABI break, but I don't see it as being detrimental (none of our existing completion callbacks are too difficult to keep working if they lose the cookie parameter). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org