On Fri, Jan 22, 2021 at 05:11:46PM +0200, Nir Soffer wrote:
> Based on the tests I did with the imageio plugin this should
> give significant performance improvement.
> I think the changes are basically:
> api version: 2
> thread model: parallel
> - Create a connection pool instead of a single connection.
> - Based on experience wit imageio client, 4 connections are a good default
> - Get connection from the pool, blocking for available instance
> - Return the connection to the pool when done or after failure
> - send a flush request for all connections in the pool
> (each http connection have a separate nbd connection inside imageio)
> - close all connections in pool
> What do you think?
The tricky thing will be getting locking right. With the PARALLEL
model you can have multiple parallel calls into the plugin even with
the same handle. The Python GIL is still active, so Python code
fragments won't be running at the same time, but it's still possible
for one thread to block in the middle of a plugin method (eg.
HTTPConnection blocking on a read), releasing the GIL, allowing
another plugin method call to start with the same handle.
The handle is a dict, which is thread safe, and we never modify
the handle during a transfer.
The only change we do is set h["failed"] to True, which is thread
safe and idempotent.
To get a connection from the handle, we will use a queue which is
thread safe. Connection are removed from the queue during use,
so only one thread can access a connection. Returning connection
to the queue is also thread safe.
So I think no extra locking is needed.
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org