Re: [Libguestfs] [PATCH libnbd] api: Get rid of nbd_connection.
On 5/23/19 10:03 AM, Richard W.M. Jones wrote:
This isn't quite finished because not all of the tests or
examples
have been updated, but it demonstrates an idea: Should we forget about
the concept of having multiple connections managed under a single
handle?
It makes sense to me.
As you discovered, the whole notion of multi-conn is tricky enough (we
can't learn if it is safe on a read-write connection until after the
first connect; do we block if one of the connections is not up; what
happens if the connections are not identical after all), and not adding
enough value (our sync APIs were holding a lock so that round-robins
were still serialized, and someone wanting performance is going to use
async anyways, but async already had to handle per-connection details
which is no different from per-handle details).
In this patch there is a single ‘struct nbd_handle *’ which manages a
single state machine and connection (and therefore no nbd_connection).
To connect to a multi-conn server you must do something like:
- Connect once, check if the server supports multi-conn.
- If it does, either disconnect and connect mulitple times "for
real", or else open further handles as required.
An example of use of the new API can be found in
examples/threaded-reads-and-writes.c after this patch is applied.
It's a lot of churn, but we haven't released yet, and I am not finding
any strong reasons why we need to keep multi-conn embedded directly in
libnbd vs. having clients manage it themselves.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 488 bytes)