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.

-- 
 [EMAIL PROTECTED]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Reply via email to