Modified:
s48/tuebingen/trunk/scheme/rts/jar-defrecord.scm
Log:
Subject: Fix hygiene bug in DEFINE-RECORD-TYPE
DEFINE-RECORD-TYPE would expand into the wrong thing if there was a
field name identical to the name of the type that appears as a
constructor argument; the constructor used that same name as a
parameter, shadowing the name for the type. The fix was to rename
those parameters before including them in the output.
track wether the thunk retuned in which case WAITING-FOR-SIGEVENT?
will now always return #f.
This makes it possible for the root-scheduler to stop even though
there are threads waiting for signals.
- Initialize READY-{READ,WRITE}-CHANNELS to () instead of #f, because
the #f's don't get overwritten when the whole thing is interrupted.
- Fix the cleanup code which was conditionalized the wrong way.
+ add errno as first argument to raise-exception os-error in prim-io.scm
+ capture os-error in with-errno-handler* and adjust exception
arguments to fit errno-handlers
- extend the VM interrupts to distinguish between read and write
events
- add new ADD-PENDING-CHANNEL instruction to the VM
- add WAIT-FOR-CHANNELS procedure to the run-time system
- implement SELECT and SELECT! on top of that in newports.scm
This runs some basic tests, but in general should be considered
largely untested.
Moreover, SELECT/SELECT! never detect any exceptional conditions---the
returned vectors are always empty. This is because the VM doesn't
really track those, and it's unclear whether it would be worth the
effort.
Scheme 48 1.0.1.
Namely, instead of associating a list of queues with every thread, we
associate a single cell, holding the thread. That cell is stored in
thread queues, and once a thread is made runnable again, the cell is
set to #f. The thread-queue accessors ignore cells containing #f.
Implement an experimental OBTAIN-LOCK-MULTIPLE to test the whole
thing.
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.
mainzelm