Displaying 7 results from an estimated 7 matches for "gl_recursive_lock_lock".
2014 May 15
2
[PATCH] Add global mutex around each C call
From: Maros Zatko <mzatko@redhat.com>
Patch adds recursive mutex around C calls, which tries to fix
potential race condition in guestfs_umount_local (see [1]).
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=917706
Maros Zatko (1):
generator: c.ml - wrap non deamon function with recursive mutex
generator/c.ml | 12 ++++++++++++
1 file changed, 12 insertions(+)
--
1.8.5.3
2014 May 16
2
Re: [PATCH] generator: c.ml - wrap non deamon function with recursive mutex
...ot;;
> +
> pr "#endif /* GUESTFS_INTERNAL_ACTIONS_H_ */\n"
>
> (* Generate guestfs-internal-frontend-cleanups.h file. *)
> @@ -1567,6 +1574,8 @@ and generate_client_actions hash () =
> c_name style;
> pr "{\n";
>
> + pr " gl_recursive_lock_lock (global_lock);\n";
> +
> handle_null_optargs optargs c_name;
>
> pr " int trace_flag = g->trace;\n";
> @@ -1617,6 +1626,9 @@ and generate_client_actions hash () =
> trace_return name style "r";
> );
> pr "\n"...
2015 Jun 06
0
[PATCH 2/5] threads: Acquire and release the lock around each public guestfs_* API.
...+ fprintf (stderr, "%s: %d: RELEASE_LOCK", __FILE__, __LINE__); \
+ abort (); \
+ } \
+ } while (0)
+#else /* !DEBUG_LOCK */
+#define ACQUIRE_LOCK(g) gl_recursive_lock_lock ((g)->lock)
+#define RELEASE_LOCK(g) gl_recursive_lock_unlock ((g)->lock)
+#endif
+
/* Default and minimum appliance memory size. */
/* Needs to be larger on ppc64 because of the larger page size (64K).
@@ -370,6 +404,9 @@ struct guestfs_h
* protects the handle.
*/
gl_recursive...
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
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
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