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 <eblake@redhat.com>
> > ---
> > 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