I take it this means that the new compiler provides signal-handling primitives of some sort? I don't remember this being mentioned at any time.

No and yes. All process support is provided via primitives, i.e. the compiler doesn't have much to do with it. And there is no signal handler in the Unix sense of the term. Rather, the TWAINS primitive *returns* whenever a signal occurs, i.e. control is returned from the process invoked by TWAINS to the process which called TWAINS (and there is always at most one process which can do the TWAINS). That is, the signal causes an involuntary transfer from the active process to the TWAINS process.

Here's the current scheduler loop (in our system, not the released system) to illustrate this:

[ | res. | currentProcess: schedule. "find next process to run" res: _TWAINS: currentProcess ResultVector: result. "transfer to it" res sendTo: self. "handle the event causing TWAINS to return" ] loop.

The first two lines find the next process to run and transfer to it. When the timer expires, control is returned to the scheduler with the string 'signal' as the return value. The third line of the loop invokes the signal method of the scheduler which handles the specific signal(s) which caused the return of TWAINS (the vector result contains additional information about this).

Similarly, if the current process caused a stack overflow, TWAINS would return with 'stackOverflow', and so on. As a last example, the code for "semaphore wait" yields the processor (after manipulating some queues) and thus causes a TWAINS to return with 'yielded'.

Since the scheduler is the only process calling TWAINS, it cannot be interrupted itself by signals; this is a very nice property of our scheme which significantly simplifies the code. I.e. when no process is waiting in a TWAINS, signals are simply buffered by the VM, and no Self-level action occurs (but the next invocation of TWAINS will return these signals immediately). There is a _BlockSignals primitive for other (short) pieces of code which must not be interrupted. It is only provided to make the implementation of Semaphores simpler (and faster) and should not be needed by normal Self code (which will use Self-level synchronisation mechanisms like semaphores).

[Uh oh, here come the bounced messages....]

Sorry for that - we get them too... maintaining a mailing list isn't easy :-(

-Urs