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

[Paul Fisher <rao gnu org>]

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.

An application only uses one type of threading library.  If it uses
more than one, it's probably all #ifdef'd.  The author should know
what type of thread library he is using.  So, under the original
solution (which I agree is not the best solution), the author would
call gdk_threads_init(FOO_THREADS).  If it returned true, it meant
that GTK+ was compiled with support for his thread package.

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

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

Yes.

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

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

Passing an environment context around is much simpler.

-- 
Paul Fisher * rao@gnu.org