Re: [gtk-list] Re: Multiple/Java thread support

[Paul Fisher <rao gnu org>]

Pablo Mejia <pjm@cctechnol.com> writes:

> At MOST he should have to switch the constant in the
> gdk_threads_init call.  You can write threaded X programs without
> knowing which thread library you will be using.

*nod*.  I see your point.  I don't do much X coding, so I've never
used Xthreads.h before.

However, you could just write gdk threading functions which operate on
an "xmutex_rec".  In effect, you could treat Xthreads as another type
of threading library.  I could be wrong here, of course.

> As I understand it, gdk will always use GDK_THREADS_INTERNAL.  So it
> would seem that gdk_thread_enter would require access to the env
> pointer.  A call to gdk_thread_enter(GDK_THREADS_INTERNAL) under the
> Java thread module ends up requiring the env pointer, as it must be
> equivalent to gdk_thread_enter(GDK_THREADS_JNI, env).  Since this is
> the case, why can't we have just the internal version.

The env pointer is different for each thread.  gdk_thread_init stores
away the env pointer and gdk_thread_{enter/leave} reuses it whenever
it's called with GDK_THREADS_INTERNAL.  It's therefore required that
the thread which calls gdk_thread_init is the same thread which is
used in the GDK event loop.

> While this can be done with #ifdef it seems that the abstraction
> which hides the JNI implementation difference should also be able to
> hide the differences between pthreads, etc.

I agree.  If Owen Taylor hasn't started working on the callback
scheme, I'll go ahead and see if I can't come up with a better
interface which works for thread libraries that do and don't need
context data.

-- 
Paul Fisher * rao@gnu.org