Displaying 9 results from an estimated 9 matches for "glthread_recursive_lock_destroy".
2018 Feb 28
0
[PATCH] lib: Don't abort if a signal handler calls exit(2) during a guestfs_* function.
...called during another guestfs_* call on the same
+ * handle. This can happen if exit(3) is called from a signal
+ * handler or another thread during a guestfs_* call, which will
+ * cause the close_handles atexit handler to run, calling us here
+ * with ignore_recursive == 1.
+ */
+ r = glthread_recursive_lock_destroy (&g->lock);
+ if (r != 0) {
+ if (r == EBUSY && ignore_recursive)
+ return;
+
+ /* If pthread_mutex_destroy returns 16 (EBUSY), this indicates
+ * that the lock is held somewhere. That means a programming
+ * error if the main program is using threads.
+ */
+...
2015 Jun 16
5
[PATCH threads v2 0/5] Add support for thread-safe handle.
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).
2017 Jun 27
0
[PATCH v3 3/5] threads: Use thread-local storage for errors.
...;
free (g->program);
free (g->path);
@@ -403,6 +402,8 @@ guestfs_close (guestfs_h *g)
free (g->backend_data);
guestfs_int_free_string_list (g->backend_settings);
free (g->append);
+ guestfs_int_free_error_data_list (g);
+ gl_tls_key_destroy (g->error_data);
r = glthread_recursive_lock_destroy (&g->lock);
if (r != 0) {
/* If pthread_mutex_destroy returns 16 (EBUSY), this indicates
diff --git a/m4/.gitignore b/m4/.gitignore
index 07960ed7b..a84b22e5c 100644
--- a/m4/.gitignore
+++ b/m4/.gitignore
@@ -248,6 +248,7 @@
/thread.m4
/time_h.m4
/timespec.m4
+/tls.m4
/ttyname_r...
2015 Jun 06
0
[PATCH 3/5] threads: Use thread-local storage for errors.
...gram);
free (g->path);
free (g->hv);
@@ -393,6 +392,8 @@ guestfs_close (guestfs_h *g)
free (g->backend_data);
guestfs_int_free_string_list (g->backend_settings);
free (g->append);
+ guestfs_int_free_error_data_list (g);
+ gl_tls_key_destroy (g->error_data);
r = glthread_recursive_lock_destroy (&g->lock);
if (r != 0) {
/* If pthread_mutex_destroy returns 16 (EBUSY), this indicates
--
2.3.1
2015 Jun 06
0
[PATCH 2/5] threads: Acquire and release the lock around each public guestfs_* API.
...if (g->state == NO_HANDLE) {
/* Not safe to call ANY callbacks here, so ... */
@@ -392,7 +393,24 @@ guestfs_close (guestfs_h *g)
free (g->backend_data);
guestfs_int_free_string_list (g->backend_settings);
free (g->append);
- gl_recursive_lock_destroy (g->lock);
+ r = glthread_recursive_lock_destroy (&g->lock);
+ if (r != 0) {
+ /* If pthread_mutex_destroy returns 16 (EBUSY), this indicates
+ * that the lock is held somewhere. That means either a
+ * programming error if the main program is using threads, or that
+ * there is an unbalanced ACQUIRE_LOCK/RELEASE_LOCK pair...
2017 Jun 27
9
[PATCH v3 0/5] threads: Add support for thread-safe handle.
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
2018 Mar 01
7
[PATCH v3 0/6] v2v: Add -o rhv-upload output mode.
v2 -> v3:
- Lots of code cleanups.
- Documentation.
However this is still spooling the file into a temporary before the
upload. It turns out that fixing this is going to require a small
change to qemu.
Rich.
2015 Jun 06
7
[PATCH 0/5] Add support for thread-safe handle.
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
2017 Jul 21
6
[PATCH v3 REPOST 0/5] threads: Add support for thread-safe handle.
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