search for: b3fef42

...ameters passed to next, create a per-connection handle, or both. Signed-off-by: Eric Blake <eblake@redhat.com> --- filters/cache/cache.c | 10 ---------- filters/error/error.c | 10 ---------- 2 files changed, 20 deletions(-) diff --git a/filters/cache/cache.c b/filters/cache/cache.c index b3fef42..19ce555 100644 --- a/filters/cache/cache.c +++ b/filters/cache/cache.c @@ -186,15 +186,6 @@ cache_config_complete (nbdkit_next_config_complete *next, void *nxdata) return next (nxdata); } -static void * -cache_open (nbdkit_next_open *next, void *nxdata, int readonly) -{ - if (next (nxdata, r...

...te/rate.c | 10 +++++----- filters/readahead/readahead.c | 3 +-- filters/stats/stats.c | 18 ++++++------------ filters/error/Makefile.am | 5 ++++- 8 files changed, 40 insertions(+), 48 deletions(-) diff --git a/filters/cache/cache.c b/filters/cache/cache.c index 6a9966e..b3fef42 100644 --- a/filters/cache/cache.c +++ b/filters/cache/cache.c @@ -209,9 +209,8 @@ cache_get_size (struct nbdkit_next_ops *next_ops, void *nxdata, nbdkit_debug ("cache: underlying file size: %" PRIi64, size); - pthread_mutex_lock (&lock); + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&...

While working on adding assertions to pthread_mutex_lock calls, I noticed that the truncate filter's use of mutex didn't really protect us, and isn't really necessary. Cleaning that up also spotted a couple of other potential cleanups. Eric Blake (4): filters: Drop useless .open callbacks truncate: Fix corruption when plugin changes per-connection size truncate: Test for safe

I do have a question about whether patch 2 is right, or whether I've exposed a bigger problem in the truncate (and possibly other) filter, but the rest seem fairly straightforward. Eric Blake (4): server: Check for pthread lock failures truncate: Factor out reading real_size under mutex plugins: Check for mutex failures filters: Check for mutex failures filters/cache/cache.c