search for: default_error_cb

...of which would ordinarily be safe when using the same + * handle from multiple threads. + * + * In each thread, the TLS data is either NULL or contains a pointer + * to a 'struct error_data'. + * + * When it is NULL, it means the stack is empty (in that thread) and + * the default handler (default_error_cb) is installed. + * + * As soon as the current thread calls guestfs_set_error_handler, + * guestfs_push_error_handler, or an error is set in the handle (calls + * like guestfs_int_perrorf and so on), the key is created and + * initialized with a pointer to a real 'struct error_data'. + * + *...

...of which would ordinarily be safe when using the same + * handle from multiple threads. + * + * In each thread, the TLS data is either NULL or contains a pointer + * to a 'struct error_data'. + * + * When it is NULL, it means the stack is empty (in that thread) and + * the default handler (default_error_cb) is installed. + * + * As soon as the current thread calls guestfs_set_error_handler, + * guestfs_push_error_handler, or an error is set in the handle (calls + * like guestfs_int_perrorf and so on), the key is created and + * initialized with a pointer to a real 'struct error_data'. + * + *...

This patch isn't ready to go upstream. In fact, I think we might do a quick 1.30 release soon, and save this patch, and also the extensive changes proposed for the test suite[1], to after 1.30. Currently it is not safe to use the same handle from multiple threads, unless you implement your own mutexes. See: http://libguestfs.org/guestfs.3.html#multiple-handles-and-multiple-threads These

Previous discussion here: https://www.redhat.com/archives/libguestfs/2015-June/thread.html#00048 v2: - Use a cleanup handler to release the lock. - Rebase to upstream. Note I have not fixed the problem(s) with error handling (patch 3).

...gt; status is data, hole, or error. The signature may still need tweaking. > Or we may even want to let the user register a set of callbacks, where a > different callback is invoked for different chunk types: > > set = nbd_callback_set_create(nbd, NBD_CMD_READ, opaque, default_cb, > default_error_cb); > nbd_callback_set_add(nbd, set, NBD_REPLY_TYPE_OFFSET_DATA, opaque, cb); > nbd_callback_set_add(nbd, set, NBD_REPLY_TYPE_OFFSET_HOLE, opaque, cb); > nbd_pread_callback(nbd, buf, count, offset, set, flags); This would also work, with the caveat that the Python bindings will currently cr...

Previously posted in 2015: v1: https://www.redhat.com/archives/libguestfs/2015-June/msg00048.html v2: https://www.redhat.com/archives/libguestfs/2015-June/msg00118.html I have rebased and tidied up the patches, fixing a few spelling mistakes, but they are broadly the same as before. I also ran all the tests, which pass. As with the previous versions, this makes a change to the API, where you

On Mon, May 27, 2019 at 09:01:01PM -0500, Eric Blake wrote: > diff --git a/lib/rw.c b/lib/rw.c > index feaf468..343c340 100644 > --- a/lib/rw.c > +++ b/lib/rw.c > @@ -234,11 +234,17 @@ int64_t > nbd_unlocked_aio_pread (struct nbd_handle *h, void *buf, > size_t count, uint64_t offset, uint32_t flags) > { > - if (flags != 0) { > + if ((flags

...as just populated, and where status is data, hole, or error. The signature may still need tweaking. Or we may even want to let the user register a set of callbacks, where a different callback is invoked for different chunk types: set = nbd_callback_set_create(nbd, NBD_CMD_READ, opaque, default_cb, default_error_cb); nbd_callback_set_add(nbd, set, NBD_REPLY_TYPE_OFFSET_DATA, opaque, cb); nbd_callback_set_add(nbd, set, NBD_REPLY_TYPE_OFFSET_HOLE, opaque, cb); nbd_pread_callback(nbd, buf, count, offset, set, flags); The idea of registering a set of callbacks to handle a particular integer command id may work w...

https://bugzilla.redhat.com/show_bug.cgi?id=769680

Previously posted in 2015: v1: https://www.redhat.com/archives/libguestfs/2015-June/msg00048.html v2: https://www.redhat.com/archives/libguestfs/2015-June/msg00118.html This series was posted about 4 weeks ago: v3: https://www.redhat.com/archives/libguestfs/2017-June/msg00287.html There is no change in this series except I rebased it against current upstream head and retested. Last time there

...(g->error_cb_stack) { next_stack = g->error_cb_stack->next; guestfs_set_error_handler (g, g->error_cb_stack->error_cb, @@ -217,6 +271,8 @@ guestfs_pop_error_handler (guestfs_h *g) } else guestfs_int_init_error_handler (g); + + RELEASE_LOCK (g); } static void default_error_cb (guestfs_h *g, void *data, const char *msg); diff --git a/src/events.c b/src/events.c index 51b9948..72a58aa 100644 --- a/src/events.c +++ b/src/events.c @@ -32,12 +32,12 @@ #include "guestfs.h" #include "guestfs-internal.h" -int -guestfs_set_event_callback (guestfs_h *g, -...

libguestfs has used double and triple underscores in identifiers. These aren't valid for global names in C++. (http://stackoverflow.com/a/228797) These large but completely mechanical patches change the illegal identifiers to legal ones. Rich.