Re: signals

[Urs Hoelzle <urs@otis.stanford.edu>]

> 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