guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread support plan with initial patch


From: Mikael Djurfeldt
Subject: Re: Thread support plan with initial patch
Date: 09 Apr 2001 05:30:26 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

NIIBE Yutaka <address@hidden> writes:

> Mikael Djurfeldt wrote:
>  > The reason is this: Many libraries that Guile might want to use are
>  > linked with libpthread.  (There can also be a situation where an
>  > application wants to use pthreads but run COOP threads within one of
>  > its threads, but that is perhaps more exotic once we have a
>  > guilepthreads implementation.)
> 
> I agree that it made sence.  GUILE_PTHREAD_COMPAT was needed, because
> the threads support was in monolithic Guile.  Here, I mean, the
> factoring-out of threads, and future.
> 
> Well, I don't think there is enough reason to keep
> GUILE_PTHREAD_COMPAT *after* the factoring-out of threads
> implementation.  If the application is linked with libpthreads, Guile
> should load the suport library of Posix threads, not COOP threads.
> 
> Therefore, I think that there's no reason having GUILE_PTHREAD_COMPAT
> in COOP support library.  Pthreads and COOP are totally different
> beasts.  Combining them is a kind of ugly hack (sorry), it depends
> much on both implementations.  It may work, but it's very difficult to
> maintain it, in practice.
> 
> I think that it's OK not supporting COOP within pthreads.  If someone
> really wants user-threads in a kernel-thread, we should provide the
> feature with another threads library (which supports user-threads in a
> kernel-thread).  It's not the business of Guile, IMNSHO.

Yes, GUILE_PTHREAD_COMPAT is an ugly hack (it's actually rather a
workaround), and, yes, to be able to run COOP threads within one
pthread is an exotic use which isn't really motivation enough to do
it.

But, as I said, the main reason is that some libraries that Guile may
want to use are linked with pthreads.

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...

So, without the GUILE_PTHREAD_COMPAT workaround, using COOP threads
together with GTK is simply not possible.

In this case one could perhaps argue that libgthread shouldn't be
linked with libpthread and maybe we could convince the people
maintaining it to change this.

But the problem is more general than so.  I don't like a situation
were COOP threads can't be used in any application where one of it's
libraries is linked with libpthreads.

If there exists a workaround for the problem, I think the gain is big
enough to motivate using it even if it is ugly.  That's why it got in
there in the first place: making it possible to use GTK with COOP
threads.

But of course, the minimum prerequisite is that it is reliable.  The
GUILE_PTHREAD_COMPAT workaround has been out there for quite some time
now.  As I've said, it is used in the Debian distribution.  There
hasn't been any trouble with it until now.

I'd like to know what the problem is before deciding to crap it, and
we can't crap it at all until we have some substitute for it's
functionality, for example a working libguilepthreads implementation.

Best regards,
/mdj



reply via email to

[Prev in Thread] Current Thread [Next in Thread]