[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: |
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.
--
- Re: Thread support plan with initial patch, (continued)
- Thread support plan with initial patch, NIIBE Yutaka, 2001/04/02
- Re: Thread support plan with initial patch, Keisuke Nishida, 2001/04/03
- Re: Thread support plan with initial patch, Mikael Djurfeldt, 2001/04/03
- Re: Thread support plan with initial patch, Mikael Djurfeldt, 2001/04/05
- Re: Thread support plan with initial patch,
NIIBE Yutaka <=
- Re: Thread support plan with initial patch, Dirk Herrmann, 2001/04/06
- Re: Thread support plan with initial patch, Neil Jerram, 2001/04/07
- Re: Thread support plan with initial patch, Dirk Herrmann, 2001/04/06
- Re: Thread support plan with initial patch, Mikael Djurfeldt, 2001/04/06
- 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