Re: missing GMainContext methods ... (fwd)
- From: michael meeks <michael meeks novell com>
- To: Owen Taylor <otaylor redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>, Tim Janik <timj imendio com>
- Subject: Re: missing GMainContext methods ... (fwd)
- Date: Fri, 23 Dec 2005 14:51:47 -0000
Hi Owen,
On Thu, 2005-12-22 at 13:04 -0500, Owen Taylor wrote:
> + * If the current thread is the owner of @context returns
> + * TRUE else FALSE. This is semantically rather different
> + * from acquiring ownership.
>
> Umm, "no duh". :-) It would be much more useful if the docs gave
> some idea of why you would want this.
Right ;-) so - in fact this is an OO.o / ORBit / a11y interaction that
is not so pleasant - and/or easy to explain. But I'll try:
When we made ORBit2 thread-safe, it was thought a good idea to use the
g_thread_self() from the thread that calls CORBA_ORB_init a 'magic'
thread: a backwards-compatible 'main' thread to which we could proxy
in-process method calls that are not on objects marked thread-safe. ie.
Thread B Thread A (magic thread)
obj->doMethod() --> invoke method
<--
etc. simple standard apartment type idea.
The problem with this is - that often 'Thread A' is _either_ a
short-lifetime thread [ eg. with Gnome-VFS usage in OO.o ] _or_ it may
be only 1 of 2 threads polling on the same GMainContext [ eg. VCL
tooltip popups ].
The latter is the most troubling case; - where our stacks look s
something like this:
obj->doMethod() g_main_ctxt_iterate(); - waiting
...
g_main_ctxt_iterate()
So - in this case - we try to proxy the method across to the main
thread - which we do - but, unfortunately that thread can never wakeup &
execute the request since Thread B actually owns the context.
So we really need a 'does_this_thread_own_the_context' call.
Now - of course we could call _acquire, then _release & execute the
call in the current thread if we got the context, or proxy it to the
main thread if we failed to get it - but there is a race with the latter
scenario.
Anyhow - hopefully that explains the need for the 1st (simple)
method ;-)
> Obviously giving a full idea
> of that would probably involve describing some horribly twisted
> and convoluted thing inside OpenOffice, but at least a few sentences
> that give an idea of the "problem domain" - if someone is trying
> to find out how to fix some problem, is function potentially useful?
I've updated the comment below.
The 2nd more complex method is as you say way more problematic - and,
the more I think about it, the less useful it is; perhaps I wanted it
because the above method didn't exist, sorry about that & thanks for the
review.
So - an updated version would be:
--- glib/gmain.c 5 Dec 2005 15:01:26 -0000 1.135
+++ glib/gmain.c 23 Dec 2005 14:50:48 -0000
@@ -3156,6 +3156,36 @@ g_main_context_wakeup (GMainContext *con
UNLOCK_CONTEXT (context);
}
+/**
+ * g_main_context_is_owner:
+ * @context: a #GMainContext
+ *
+ * Determines whether this thread holds the (recursive)
+ * ownership of this #GMaincontext. This is useful to
+ * know before waiting on another thread that may be
+ * blocking to get ownership of @context.
+ *
+ * Returns: TRUE if current thread is owner of @context.
+ **/
+gboolean
+g_main_context_is_owner (GMainContext *context)
+{
+ gboolean is_owner;
+
+ if (!context)
+ context = g_main_context_default ();
+
+#ifdef G_THREADS_ENABLED
+ LOCK_CONTEXT (context);
+ is_owner = context->owner == G_THREAD_SELF;
+ UNLOCK_CONTEXT (context);
+#else
+ is_owner = TRUE;
+#endif
+
+ return is_owner;
+}
+
/* Timeouts */
Thanks,
Michael.
--
michael meeks novell com <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]