On Tue, Nov 04, 2025 at 12:13:52PM +0100, Kevin Wolf wrote: > Am 03.11.2025 um 21:10 hat Eric Blake geschrieben: > > In qemu-nbd and other NBD server setups where parallel clients are > > supported, it is common that the caller will re-register the same > > callback function as long as it has not reached its limit on > > simultaneous clients. In that case, there is no need to tear down and > > reinstall GSource watches in the GMainContext. > > > > Signed-off-by: Eric Blake <[email protected]> > > --- > > io/net-listener.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/io/net-listener.c b/io/net-listener.c > > index 0adbc409cf2..e89286ea63c 100644 > > --- a/io/net-listener.c > > +++ b/io/net-listener.c > > @@ -147,6 +147,10 @@ void > > qio_net_listener_set_client_func_full(QIONetListener *listener, > > { > > size_t i; > > > > + if (listener->io_func == func && listener->io_data == data) { > > + return; > > + } > > Wouldn't a change of listener->io_notify also be significant?
On paper, yes. In practice: io_notify is usually either a free-like function (including obect_unref in this bucket), or NULL. In the former, you are passing in a malloc'd or reference-counted object, where the cleanup action at notify time will never vary (the nature of the object being passed in determines how to clean up when it is no longer in use). In the latter, passing NULL means no cleanup is necessary. I struggle to see a scenario where you would register a callback opaque pointer with one cleanup function, and then change your mind to re-register the same object but a different io_notify cleanup function. But I'm not opposed to adding the additional check for an unchanged io_notify in v2. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
