About cleaning up the thread stuff

[Marius Vollmer <marius.vollmer@uni-dortmund.de>]

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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel