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: NIIBE Yutaka
Subject: Re: Thread support plan with initial patch
Date: Fri, 6 Apr 2001 19:31:23 +0900 (JST)

Mikael Djurfeldt wrote:
 > But what I meant with "have a look at" was more generally to look at
 > that solution (the thread interface, the separation of code specific
 > to a certain thread library out of libguile etc), comment on it, and
 > see if you can build upon that when working on the pthreads support.

Yes.  After I've checked that it works fine, I'm reading the code.
I think that I've done the merge into current code.

 > An application using your pthreads support would then be linked with
 > these tree libraries:
 > 
 >   libguile              providing the Scheme level thread primitives
 >   libguilepthreads      providing "glue code" to plug into the thread 
 > interface
 >   libpthreads           the POSIX thread library

I see.  I think that it is possible to do that.  I don't know about
the perfomance impact, though.

I think that we need to implement "Null"-thread support (for non
threaded applications) at first.  For the "Null"-thread support, the
methods defined by the threads interface are categorized into four
parts:

        (a) The methods which raise error when called
            spawn_thread, cond_wait...
        (b) The methods just do nothing
            cond_signal, cond_signal_broadcast, ...
        (c) The methods which should be implemented
            thread_local/thread_specific data, ...
        (d) Special ones:
            mutex_lock, mutex_unlock         ------------- (*1)

To change the threads support dynamically (Null, Pthreads or COOP), we
need some changes for libguile.  I think that modules should provide a
hook for thread-support change, something like:

        threads_support_change_hook (xxx)
        {
            check there's no threads waiting on condvar or mutex
            check there's no threads holding mutex  ------------- (*2)
            free all mutexes and condvars (in old package)
            allocate all mutexes and condvars (in new package)
            migrate thread_local/thread_specific data from old to new
            module specific code...
        }

(*1)(*2): We need to make sure that no threads are holding the mutex.
To implement it, we should do something with mutex_lock/unlock in
"Null" supports, instead of just do nothing for that.

It seems that the modules we need to change are just a few: gc.c,
goops.c, and readline.c.
-- 



reply via email to

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