search for: 63f0eb0889

I'm observing a difference in timing on nbdkit shutdown that is dependent on client behavior, and I wonder if that's a bug, but I can't figure out where to patch it. When there is no connection present, sending SIGINT to nbdkit terminates immediately. If, on the other hand, there is a single client currently connected, the termination behavior on SIGINT depends on what the client has

...d, the > termination behavior on SIGINT depends on what the client has done: if > the client is currently silent with regards to issuing > transmission-phase transactions, nbdkit hangs for 5 seconds, then > forcibly tears down the connection: I'm guessing it's because of commit 63f0eb0889c8f8a82ba06a02a8a92d695902baad which I added to fix a race in plugin_cleanup(). See also: https://www.redhat.com/archives/libguestfs/2017-September/msg00226.html [...] > Why does current traffic from the client cause the plugin to be torn > down faster? Does it matter? I believe because th...

...n behavior on SIGINT depends on what the client has done: if >> the client is currently silent with regards to issuing >> transmission-phase transactions, nbdkit hangs for 5 seconds, then >> forcibly tears down the connection: > > I'm guessing it's because of commit 63f0eb0889c8f8a82ba06a02a8a92d695902baad > which I added to fix a race in plugin_cleanup(). See also: > https://www.redhat.com/archives/libguestfs/2017-September/msg00226.html > > [...] >> Why does current traffic from the client cause the plugin to be torn >> down faster? Does it m...