On Tue, Dec 18, 2018 at 04:24:26PM +0400, Marc-André Lureau wrote: > Hi > > On Tue, Dec 18, 2018 at 2:01 PM <elohi...@gmail.com> wrote: > > > > From: Xie Yongji <xieyon...@baidu.com> > > > > New option "disconnected" is added to init the chardev socket > > in disconnected state. Then we can use qemu_chr_fe_wait_connected() > > to connect when necessary. Now it would be used for unix domain > > socket of vhost-user-blk device to support reconnect. > > What difference does that make if you wait for connection in > qemu_chr_fe_wait_connected(), or during chardev setup? > > "disconnected" is misleading, would it be possible to reuse > "wait/nowait" instead?
Currently we default to doing a blocking connect in foreground, except if reconnect is non-zero, in which case we do a connect async in the background. This "disconnected" proposal effectively does a blocking connect, but delayed to later in startup. IOW, this could already be achieved if "reconnect" were set to non-zero. If the usage doesn't want reconnect though, I tend to agree that we should use the exisiting wait/nowait options to let it be controlled. I don't see that this "disconnected" option gives a compelling benefit over using wait/nowait. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
