scsh-0.6/scheme/rts
sperber 1d35626709 Redo the forking-without-the-threads fix in a way not involving
command levels (as there *are* no command levels for things like scsh
-c):

There's now a new asynchronous event, similar to SPAWN, called NARROW.
It spawns off a new scheduler with just one thread (which runs the
thunk provided as an argument to NARROW) and blocks the current one
until the narrowed scheduler finishes.

For this to work, two schedulers need to be in place: the root
scheduler which performs the housekeeping, and another one inside that
which is the one the program uses---otherwise it's the root scheduler
that's blocked, and that means no housekeeping gets done.  This is
trivially the case for interactive mode, as the command-levels all
have their own schedulers, but we also need to make sure scsh's entry
point fires up its own initial scheduler.
2002-05-03 13:42:36 +00:00
..
base.scm
bignum.scm
channel-io.scm
channel-port.scm
channel.scm
condition.scm
continuation.scm
current-port.scm
defenum.scm
env.scm
eval.scm
exception.scm
floatnum.scm
init.scm
innum.scm
interrupt.scm
jar-defrecord.scm
lize.scm
lock.scm
low.scm
method.scm
number.scm
numio.scm
population.scm
port.scm
ratnum.scm
read.scm
recnum.scm
record.scm
root-scheduler.scm
scheduler.scm Redo the forking-without-the-threads fix in a way not involving 2002-05-03 13:42:36 +00:00
session.scm
sigevents.scm
signal.scm
sleep.scm
template.scm
thread-cell.scm
thread-env.scm
thread.scm Redo the forking-without-the-threads fix in a way not involving 2002-05-03 13:42:36 +00:00
time.scm
util.scm
wind.scm
write.scm
xnum.scm
xprim.scm