On 5/22/19 4:28 AM, Richard W.M. Jones wrote: >> Should this be a bool parameter for the caller to opt-in to? In one >> direction, returning as soon as possible allows the caller to issue >> further synchronous commands which will pick the ready connections and >> skip the ones still initializing, to at least get lower latency on the >> first commands and better performance later as more connections come up; >> in the other direction, waiting to return until all connections are made >> makes it easier to issue async commands on any connection without >> worrying if the connection is up. The choice of the parameter to pass in >> depends, then, on whether the caller plans to make future sync calls or >> async calls. > > It could be. On the other hand if people want to do complicated stuff > then there is the AIO interface.
True enough. A caller that wants to avoid latency should be using AIO rather than sync. So this change makes sense to me overall. >>> For ‘nbd_connect_command’, it essentially ignored multi-conn anyway, >>> and I changed it so that it waits for conn[0] to get connected and >>> returns, the other connections (if they exist) being ignored. It >>> should probably be an error for the user to enable multi-conn on the >>> handle and then use nbd_connect_command, but I did not make that >>> change yet. >> >> Yes, that change (as a separate patch) makes sense. > > Even more radical, what if we prevent the use of multi-conn at all > with the synchronous interface? (I don't think this is a good idea, > just putting it out there for discussion). multi-conn + synchronous still makes sense (the fact that you round-robin between connections is already nice); it's only the command interface (where you can't make more connections, because you are limited to stdin/stdout) where an error would be appropriate. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
