[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
About cleaning up the thread stuff
From: |
Marius Vollmer |
Subject: |
About cleaning up the thread stuff |
Date: |
Tue, 18 Jan 2005 16:54:43 +0100 |
User-agent: |
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) |
Hi,
I am now turning to go over the thread stuff in Guile, first to
understand what we have, and then to maybe clean it up and document it
authoritatively.
I'd like to give you advance warning of where I am heading at the
moment so that you can talk me out of doing the wrong things. All of
this might change as I make up my mind, but please comment anyway.
I do the work on the 'branch_mvo-thread-cleanup' branch.
- First, I want to rip out the plugin interface since it confuses me
a bit. Maybe I'll put it back in later, but to get started, I only
want to deal with POSIX pthreads. Guile will be able to use
pthreads, but can also be compiled without pthreads.
I consider the pthread API to be the plugin interface where
different threading implementations can be selected. Maybe it is
useful to make the names configurable that Guile uses for the
pthread API, but it should always be a pthread API.
- Then I want to specify clearly the two modes that a program can be
in: 'guile mode' and 'non-guile mode'. In guile mode, a program
can use functions from the Guile API and must play by the rules of
Guile, in non-guile mode, it can not call Guile functions (safe a
very few exceptions) but does not need to play by the rules.
The rules are basically that a thread must periodically execute
SCM_TICK and must only block in functions provided by Guile. If
you want to block in other ways, you must first leave guile mode
(and enter again after blocking). Stack frames that are created in
non-guile mode are not scanned by the GC so you can not store SCM
values in them.
You can enter guile mode in any thread, but Guile offers
convenience functions for creating threads that start out in Guile
mode. When a thread first enters guile mode, it gets a 'guile
personality' and shows up in (all-threads), for example. When it
leaves guile mode, it keeps this personality and is only removed
from (all-threads) when it terminates.
- For Scheme (and also for C code that wants to use them), I want to
offer 'fat' mutexes and condition variables.
These are mutexes and condvars that are as nice as reasonable: they
are fair, you can query easily where threads are blocking, asyncs
are handled while blocking, dead-locks might be detected and
mutexes can be recursive, for example.
No other kinds of mutexes are offered, for example, all mutexes
used by Scheme code will be of this 'fat' kind. (The low level C
API will disappear.) If you want to use pthread mutexes, you can,
but you must leave guile mode while blocking on them.
To make this easy, there will be functions like
scm_pthread_mutex_lock that is just like pthread_mutex_lock but
will properly leave guile mode while blocking.
(The only advantage that pthread mutexes have over these 'fat' ones
is that they are slightly faster and slightly smaller. I don't
consider these reasons good enough to lose the advantages of the
fat ones.)
- About cleaning up the thread stuff,
Marius Vollmer <=