Re: [patch] Multiple/Java thread support

[Pablo Mejia <pjm cctechnol com>]

    Owen> I'm not completely sure this is the right level of
    Owen> abstraction, perhaps it should be lower:

    Owen>  gpointer (*create_mutex) (void);
    Owen>  void (*lock_mutex)   (gpointer mutex);
    Owen>  void (*unlock_mutex) (gpointer mutex);

    Owen> But you get the idea -- new thread implementations should be
    Owen> set at run time, not compile time. The argument given to
    Owen> --with-threads=pthreads, or whatever, just says which a
    Owen> default thread mechanism should be compiled in.

    Owen> Does this sound reasonable?

This sounds better than the suggested patch.  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.

I am not a gtk guru by any means, but I think the function pointers
above should be used.  Then at most a recompile would be needed to use
an app under a different thread implementation.  And if dynamic
loading of the thread support functions, this would not be necessary.

I believe that gtk (gdk/glib) should define an abstraction layer
providing a simple thread (mutex, cond variable, etc.) interface.
This would increase the portability of gtk apps considerably.
Something like the macros defined in Xthreads.h is more like what we
need.

I think that having multiple function signatures for the different
implementations is evil.  gdk_threads_enter should have the same
signature no matter what the implementation.  For example, for the
Java thread interface, is it necessary to pass the environment
pointer?  It seems like the Java implementation of gdk_threads_enter
should be able to get this value itself (is this totally wrong?).

Pablo