search for: error_cb_stack

...ed. (The pthread_key* API doesn't give + * us any other way to do this, in particular pthread_key_delete + * doesn't call the destructor associated with the key). + */ + +static void default_error_cb (guestfs_h *g, void *data, const char *msg); + +/* Stack of old error handlers. */ +struct error_cb_stack { + struct error_cb_stack *next; + guestfs_error_handler_cb error_cb; + void * error_cb_data; +}; + +/* Error data, stored in thread-local storage in g->error_data key. */ +struct error_data { + /* Linked list of error_data structs allocated for this handle. */ + struct...

...d. (The pthread_key* API doesn't give + * us any other way to do this, in particular pthread_key_destroy + * doesn't call the destructor associated with the key). + */ + +static void default_error_cb (guestfs_h *g, void *data, const char *msg); + +/* Stack of old error handlers. */ +struct error_cb_stack { + struct error_cb_stack *next; + guestfs_error_handler_cb error_cb; + void * error_cb_data; +}; + +/* Error data, stored in thread-local storage in g->error_data key. */ +struct error_data { + /* Linked list of error_data structs allocated for this handle. */ + struct...

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).

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

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

...h *g, void **data_rtn) +{ + guestfs_error_handler_cb r; + + ACQUIRE_LOCK (g); + r = unlocked_get_error_handler (g, data_rtn); + RELEASE_LOCK (g); + return r; +} + void guestfs_push_error_handler (guestfs_h *g, guestfs_error_handler_cb cb, void *data) { struct error_cb_stack *old_stack; + ACQUIRE_LOCK (g); + old_stack = g->error_cb_stack; g->error_cb_stack = safe_malloc (g, sizeof (struct error_cb_stack)); g->error_cb_stack->next = old_stack; @@ -201,6 +251,8 @@ guestfs_push_error_handler (guestfs_h *g, g->error_cb_stack->error_cb_data...

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

....c @@ -253,6 +253,9 @@ void guestfs_close (guestfs_h *g) { struct qemu_param *qp, *qp_next; +#ifndef HAVE_ATTRIBUTE_CLEANUP + struct deferred_free *dfp, *dfp_next; +#endif guestfs_h **gg; if (g->state == NO_HANDLE) { @@ -324,6 +327,18 @@ guestfs_close (guestfs_h *g) while (g->error_cb_stack) guestfs_pop_error_handler (g); +#ifndef HAVE_ATTRIBUTE_CLEANUP + /* For compilers that don't support __attribute__((cleanup(...))), + * free any temporary data that we allocated in CLEANUP_* macros + * here. + */ + for (dfp = g->deferred_frees; dfp; dfp = dfp_next) { + dfp...

...} else if (f->result == 1) { + return 0; + } + } + + /* All specified groups available. */ + return 1; } diff --git a/src/guestfs-internal.h b/src/guestfs-internal.h index 49da6fe..bc03ccc 100644 --- a/src/guestfs-internal.h +++ b/src/guestfs-internal.h @@ -360,6 +360,12 @@ struct error_cb_stack { void * error_cb_data; }; +/* Cached queried features. */ +struct cached_feature { + char *group; + int result; +}; + /* The libguestfs handle. */ struct guestfs_h { @@ -502,6 +508,10 @@ struct guestfs_h unsigned int nr_requested_credentials; virConnectCredential...

Rename the current available and feature_available into internal daemon functions, and provide non-daemon functions wrapping them at library side. This will make it possible to e.g. add caching for them. Should be only refactoring, no actual behaviour change. --- daemon/available.c | 4 +- generator/actions.ml | 192 ++++++++++++++++++++++++++++----------------------- po/POTFILES |

I've been taking a long hard look at the protocol layer. It has evolved over a long time without any particular direction, and the result is, to say the least, not very organized. These patches take a first step at cleaning up the mess by abstracting out socket operations from the rest of the code. The purpose of this is to allow us to slot in a different connection layer under the

This patch series moves some files and directories around but is only code motion (or supposed to be). A new directory, common/, is created for all of the common code which is currently shared in random ways between parts of the project. And src/ becomes lib/ (the largest change, but mostly mechanical). In full this series makes the following changes: src/libprotocol -> common/protocol

Previous patch series was posted here: https://www.redhat.com/archives/libguestfs/2017-January/msg00059.html v2 simply extends this patch series to cover the extra directories common/edit, common/progress, common/windows and common/parallel. The only remaining item is to consider whether we should rename mllib to something else, mlcommon was my suggestion. Rich.

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.