Re: Multiple/Java thread support

[Pablo Mejia <pjm cctechnol com>]

>>>>> "Paul" == Paul Fisher <rao@gnu.org> writes:

    Paul> Pablo Mejia <pjm@cctechnol.com> writes:
    >> The main problem I see with the first patch is that it requires
    >> modifying the gtk app to switch the underlying thread library.
    >> So even if gtk would internally work with pthreads or Sun
    >> threads, source changes would be required in the app.  IMHO
    >> this is the wrong way to go.

    Paul> An application only uses one type of threading library.  If
    Paul> it uses more than one, it's probably all #ifdef'd.  The
    Paul> author should know what type of thread library he is using.

I don't agree with this.  The author doesn't always need to know which
thread library he is using.  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.  Just
use the interfaces provided in Xthreads.h

    Paul> How does the gtk app need to be modified?  If a native
    Paul> application used Cthreads, you certainly wouldn't want GTK+
    Paul> to go off and use Pthread mutexes.

This may be full of stupid ideas as I am VERY NEW at gtk.  That said :)

I guess I wasn't very clear.  Say I have an application which uses one
thread to draw into a drawing area, and another thread for the rest of
the GUI.  I have apps which do this in Motif, so there is a use for
it.  Under Sun OS you get a choice of using pthreads or Sun threads,
under Linux you have don't get Sun threads.  

If I wrote my gtk app under Solaris, I might use Sun threads.  Thus I
would have gdk_threads_init(SUN_THREADS) in the app.  Now that app is
to be ported to Linux.  Since we don't have Sun threads this will
obviously need to be modified.  Since I as the application writer
don't really care what thread implementation is being used this is not
optimal.  In some cases I might need to know which thread library is
being used, but not in general.

    >> For example, for the Java thread interface, is it necessary to
    >> pass the environment pointer?

    Paul> Yes.

    >> It seems like the Java implementation of gdk_threads_enter
    >> should be able to get this value itself (is this totally
    >> wrong?).

    Paul> It can.  However, it's very very very icky.  For java
    Paul> implementations that support multiple virtual machines in
    Paul> memory at the same time, it's even worse.

    Paul> Passing an environment context around is much simpler.

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.

There are two goals to be accomplished.  One is to allow gtk to use
Java.  This requires gtk to use Java thread primitives.  Since the
Java native method writer is tied to Java It is not a burden to have
the Java native method writer use gdk_thread_enter(GDK_THREADS_JNI).
But the gtk user which is using straight C, should be able to switch
from a pthread to a Sun thread implementation without changing source
code.  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 have some more comments, but will wait for a reply to point out my
errors before I say anything more foolish.  Pablo