[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thread support plan with initial patch
From: |
NIIBE Yutaka |
Subject: |
Re: Thread support plan with initial patch |
Date: |
Mon, 9 Apr 2001 13:36:23 +0900 (JST) |
Mikael Djurfeldt wrote:
> Example: An application writer wants to use GTK together with COOP
> threads. The way to do this is to plug in COOP threads into glib's
> thread interface. (An implementation of this exists as the CVS module
> guile-gtkthreads.) However, this requires linking with libgthread,
> which, in turn, is linked with libpthreads...
[...]
> I'd like to know what the problem is
Yes, I will try to find the problem...
Anyway, again here's what I think:
In C Library (or X11 library) which supports multi-threaded
application, there're the places to call of POSIX threads, so that
critical sections are protected. Those will be enabled when
libpthreads is linked explicitly, or else, it calls null function. It
is implemented using weak symbols. This is the trick of
multi-threaded library.
Consider the following case:
An application writer do *not* want to use POSIX threads feature, but
just only COOP threads feature. He does *not* link the application
with libpthreads. However, if libguileqthreads are linked with
libpthreads (and this is the case, now), it loads POSIX threads
automatically. Because POSIX thread implementation is not designed
for COOP, it is difficult to support this case (in my opinion).
Well.... OK, for now, how about having two?
(1) libguileqthread-pthread
Compiled with GUILE_PTHREAD_COMPAT and linked with libpthread
(2) libguileqthread
Compiled with no GUILE_PTHREAD_COMPAT and linked with
no libpthread
Then, Guile loads the one of them on start-up time, examining the
application (if the application is linked with libpthread, it load
libguileqthread-pthread, or else libguileqthread).
This is cleaner approach, and we can test loading different threads
implementations. Then, add (3) POSIX threads support. Perhaps,
one could deprecate (1) at that time.
--
- Re: Thread support plan with initial patch, (continued)
- Re: Thread support plan with initial patch, Marius Vollmer, 2001/04/06
- Re: Thread support plan with initial patch, Mikael Djurfeldt, 2001/04/06
- Re: Thread support plan with initial patch, Dirk Herrmann, 2001/04/10
- Re: Thread support plan with initial patch, NIIBE Yutaka, 2001/04/07
- Re: Thread support plan with initial patch, NIIBE Yutaka, 2001/04/07
- Re: Thread support plan with initial patch, Mikael Djurfeldt, 2001/04/07
- Re: Thread support plan with initial patch, NIIBE Yutaka, 2001/04/08
- Re: Thread support plan with initial patch, Mikael Djurfeldt, 2001/04/08
- Re: Thread support plan with initial patch,
NIIBE Yutaka <=
- Re: Thread support plan with initial patch, Mikael Djurfeldt, 2001/04/09
- Re: Thread support plan with initial patch, Rob Browning, 2001/04/09
- Re: Thread support plan with initial patch, Rob Browning, 2001/04/09
- Re: Thread support plan with initial patch, NIIBE Yutaka, 2001/04/09
- Re: Thread support plan with initial patch, Rob Browning, 2001/04/09
- Re: Thread support plan with initial patch, Dirk Herrmann, 2001/04/10
- Re: Thread support plan with initial patch, NIIBE Yutaka, 2001/04/10
- Re: Thread support plan with initial patch, Dirk Herrmann, 2001/04/10
- Re: Thread support plan with initial patch, Dirk Herrmann, 2001/04/06