Warning: Unstable POSIX threads support comitted to CVS

[Mikael Djurfeldt]

Hi,

Based on Marius copt threads work, I've now put together an initial
version of full POSIX threads support with preemptive thread
scheduling.  This is especially good to have if you, like me, use
multi-cpu machines.

Attached to this letter is an example program:

  par-fib N DEPTH --> fibonacci number N

The number is computed by forking to DEPTH levels.
For example, (par-fib 100 4) creates 31 threads (with 16 threads at
the base level, reverting to iterative computation of the rest).
(par-fib 100 5) crashes for me... :)

Well, yes, the current state of the code is slightly broken.  Just as
before this change, the null-threads alternative won't build, and the
threading alternative is the default.  The idea is that we for the
coming couple of weeks can make a collaborative effort of finding bugs
and fundamental problems.

However, single-thread use seems stable (although there could be some
problems with errors in macro transformers).

We need to work on signal delivery and exceptions.  One suggestion is
that we continue to *only* deliver signals at SCM_ASYNC_TICK points.
The effect of signal delivery (normally a throw) is then pretty well
controlled.  A novel (?) suggestion is this:

It is very irritating that signals are delivered to whatever thread
happens to run for the moment.  Is it possible to add explicit
interactive control over which thread is the "foreground" thread?
Only the "foreground" thread gets signal delivery (=> that thread gets
its async lists marked regardless of which thread reacted on the
signal).  Normally, the "foreground" is the repl loop thread, and we
can have a small "command language" (perhaps ordinary scheme
procedures) to inspect status of the other threads and explicitly
deliver signals like "SIGINT".

One further area which needs work is the current recursive critical
sections (SCM_REDEFER/REALLOW_INTS, SOURCE_SECTION in eval.c etc).
They need to be optimized (use real POSIX recursive mutecis if
available).  We should also add a mechanism for resetting (unlocking)
the associated mutecis on an error throw.  This can be made by adding
a line for registering the critical section in
SCM_REC_CRITICAL_SECTION in snarf.h.

I and Marius hope to fix the most basic problems within a few days.
Then I think we'll have an acceptable level of stability.  And, as
Marius have said before, the thread suppport is in a state of flux.
Much can still change...

(BTW, there seems to be some unrelated build problem right now due to
the recent change to versioning.)

Best regards,
Mikael D.

fib.scm
Description: Thread test program