Re: scm_i_fraction_reduce thread safety

[Rob Browning]

Dirk Herrmann <address@hidden> writes:

> The underlying problem here is, that guile's space of cells is
> actually shared memory between all threads. To make things
> transparently safe for scheme code would either forbid thread
> switches to happen at certain points in time (which makes concurrent
> threads impossible), or to add a lot more locking when accessing the
> cell space.

This raises something I've been thinking about off and on for quite a
while.  My guess is that we may have some fairly substantial
performance and design tradeoffs the more concurrency and "transparent
safety" we try to support in a fully preemtive environment.

As a trivial example, if you just want "all user C calls to be safe",
then you probably have to put guards around the bodies of essentially
every function (and or in the code generated by every macro).  One
exception I can think of is a compiler which knew enough to be able to
omit the locks for sections of code that it could either tell were
otherwise protected, or that it had otherwise protected on a higher
level.

In any case, do we have a "current plan" with respect to threading,
and on a related note, do we have any plans to consider anything other
than our current one interpreter per-process arrangement?

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4