similar to: [libnbd PATCH] docs: Mention that nbd_close is not thread-safe

On Thu, Jul 25, 2019 at 09:41:01AM +0100, Richard W.M. Jones wrote: >On Wed, Jul 24, 2019 at 03:14:28PM -0500, Eric Blake wrote: >> Closing the handle in one thread while another thread is locked causes >> undefined behavior (as closing does not obtain a lock, and can cause >> use-after-free or other nasty problems to the thread that does own the >> lock). However, it

On Wed, Jul 24, 2019 at 03:14:28PM -0500, Eric Blake wrote: > Closing the handle in one thread while another thread is locked causes > undefined behavior (as closing does not obtain a lock, and can cause > use-after-free or other nasty problems to the thread that does own the > lock). However, it is not sensible to try and obtain a lock in > nbd_close, as POSIX says that it is also

On 7/25/19 3:56 AM, Martin Kletzander wrote: > On Thu, Jul 25, 2019 at 09:41:01AM +0100, Richard W.M. Jones wrote: >> On Wed, Jul 24, 2019 at 03:14:28PM -0500, Eric Blake wrote: >>> Closing the handle in one thread while another thread is locked causes >>> undefined behavior (as closing does not obtain a lock, and can cause >>> use-after-free or other nasty

Rich recently patched things to generate one man page per function rather than libnbd-api.3 (nice), but in doing so got stumped by a problem with a fresh git clone (automake fails for any 'include' directive that does not already exist). I've figured out how to hack around it, but the hack requires GNU make. We already use GNU make constructs elsewhere (such as $(wildcard)), but

This patch adds support for symbol versions. It is based on what libvirt does. The generated syms file looks like: LIBNBD_1.0 { global: nbd_...; nbd_...; local: *; }; In a future stable 1.2 release, new symbols would go into a new section which would look like this: LIBNBD_1.2 { global: nbd_new_symbol; nbd_another_new_symbol; local: *; } LIBNBD_1.0; In my testing the

I still need to wire in the use of *_notify functions into nbdkit to prove whether it makes the code any faster or easier to maintain, but at least the added example shows one good use case for the new API. Eric Blake (6): api: Add nbd_aio_in_flight generator: Allow DEAD state actions to run generator: Allow Int64 in callbacks states: Prepare for aio notify callback api: Add new

On 7/24/19 11:54 AM, Richard W.M. Jones wrote: > Previously closures had a crude flag which tells if they are > persistent or transient. Transient closures (flag = false) last for > the lifetime of the currently called libnbd function. Persistent > closures had an indefinite lifetime which could last for as long as > the handle. In language bindings handling persistent closures

I think I've addressed everything that was raised in review. Some of the highlights: - Callbacks should be freed reliably along all exit paths. - There's a simple test of closure lifetimes. - I've tried to use VALID|FREE in all the places where I'm confident that it's safe and correct to do. There may be more places. Note this is an optimization and shouldn't

Reverts commit 387cbe67c3db27e8a61117fedb6e7fad76e409ef. --- generator/generator | 18 +++++++++++++++++- lib/handle.c | 28 +++++++++++++++++++++++++++- tests/closure-lifetimes.c | 4 +++- 3 files changed, 47 insertions(+), 3 deletions(-) diff --git a/generator/generator b/generator/generator index 2cd83f1..25e4aa5 100755 --- a/generator/generator +++ b/generator/generator

This is a simple patch which stops nbd_close from waiting too long for a server subprocess to shut down. I wanted to send SIGHUP because the server will be able to catch it and do a clean shutdown if that is required. Is another signal better? Is it right to send a signal here? Rich.

On Fri, Jul 14, 2023 at 09:13:42AM +0200, Laszlo Ersek wrote: > On 7/13/23 21:29, Eric Blake wrote: > > The documentation has claimed since commit 6f4dcdab that any > > completion callback will be called exactly once; but this is not > > consistent with the code: if nbd_aio_* itself returns an error, then > > nothing is queued and the user does not need to wait for a

On 7/25/19 12:43 PM, Richard W.M. Jones wrote: > $ time nbdsh -c 'h.connect_command (["nbdkit", "-s", "null", "size=512", "--filter=delay", "delay-read=10"]); b = nbd.aio_buffer(1); h.aio_pread (b, 0); del (h)' > real 0m10.499s > user 0m0.065s > sys 0m0.023s > > With this patch the elapsed time is near

One API change, some small documentation changes.

This is my proposal for fixing the documentation to match practice (namely, that completion.callback is not invoked in the cases where the aio call itself reports errors); we could instead try to go the other direction and tweak the generator to guarantee that both completion.callback and completion.free are reached no matter what, but that felt more invasive to me. Eric Blake (2): api: Tighten

Patches 1 & 2 are rather complex, but the end result is that we pass closures + user_data + free function in single struct parameters as I described previously in this email: https://www.redhat.com/archives/libguestfs/2019-August/msg00210.html Patch 3 adds a convenient FREE_CALLBACK macro which seems a worthwhile simplification if you buy into 1 & 2. Patch 4 adds another macro which is

On Tue, Jul 30, 2019 at 11:21:25AM -0500, Eric Blake wrote: > On 7/30/19 10:36 AM, Richard W.M. Jones wrote: > > +When the command completes, C<callback> > > will be invoked as described in L<libnbd(3)/Completion callbacks>. > > + > > Do we need wording anywhere (probably in the .pod, so we only state it > once) that mentions that the callback routine is

RFC because this is an API break, but we haven't declared stable API yet. If we like it, I'm working on using libnbd to implement the nbdkit-nbd plugin; knowing whether it is API version 0.1 or 0.2 will be useful. I also dabbled with allowing optional parameters in python, although my OCaml is weak enough that there may be cleaner ways to approach that. Eric Blake (4): api: Add flags

I'm not observing any noticeable performance differences, but I'm liking the diffstat. I can't push this patch until we release a new libnbd version with the _notify API addition, but am posting it now for playing with things. Eric Blake (2): nbd: Move transaction info from heap to stack nbd: Use nbdkit aio_*_notify variants plugins/nbd/nbd.c | 217

This applies on top of the OClosure v2 series posted a few minutes ago. Rich.

On v1, we discussed whether cmds_to_issue needed to be a list, since it never had more than one element. I played with the idea of making it a list, and allowing the client to queue up new commands regardless of whether the state machine is currently in READY. I also polished up the tmp demo into a bit more full-fledged example file, worth including since it also let me discover a hard-to-hit race