Number: 410

Date: 31-Mar-84 14':06':02

Submitter: Sannella.PA

Source: vanMelle.pa

Subject: document \PERIODIC.INTERRUPT

Lisp Version: 

Description: '
Received': from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 28 MAR 84 13':45':34 PST'
Date': Wed, 28 Mar 84 13':45':07 PST'
From': Eric Schoen <Schoen@SUMEX-AIM.ARPA>'
Subject': Periodic interrupts'
To': 1100support.pasa'
'
The scheme I described in this space previously was a bit too flakey'
for general use.  I did come up with something more reliable.  I '
defined a new class of interrupt called SCHEDULER.  I then armed ↑S to'
be the scheduler interrupt.  At every \PERIODIC.INTERRUPT I '
uninterruptably (replace (INTERRUPTSTATE INTCHARCODE) of \INTERRUPTSTATE'
with (CHARCODE ↑S)) and (SETQ \PENDING.INTERRUPT T).  When the '
periodic interrupt goes away, I get a lisp software interrupt.  For'
class SCHEDULER, INTERRUPTED was redefined to call the function SCHEDULER,'
which does something like suspend and wake various processes.  The people'
trying to use this stuff are simulating a data acquisition system in which'
processes have various priorities, and are using their own priority'
mechanism, rather than trying to use those parts of PROCESSWORLD priorities'
which are implemented.'
'
The other benefit from this code is that with \PERIODIC.INTERRUPT turned'
off, I can still force a block during a non-blocking computation simply by'
typing ↑S.'
'
And yes, it''s very dangerous and things still crash now and then, but'
it''s sufficient to simulate our systems.'
'
Eric'
'
-----'
'
Date': 30 Mar 84 12':42 PST'
From': vanMelle.pa'
Subject': Re': Periodic Interrupts'
In-reply-to': Dering.pasa''s message of 28 Mar 84 17':13 PST'
To': Dering.pasa'
cc': 1100Support.pasa, LispSupport, vanMelle.pa'
'
The main thing Eric needs to know is that the \PERIODIC.INTERRUPT definition MUST be of the form'
'
  (if \INTERRUPTABLE'
    then do-something)'
'
In other words, if \INTERRUPTABLE (a specvar) is NIL, the function MUST immediately return.'
'
Otherwise, \PERIODIC.INTERRUPT should be no more dangerous to use than an interrupt caused by an interrupt character, except, of course, that since it happens much more frequently than keyboard interrupts, there is a much higher chance that it will discover places in the system that should have been interrupt protected.  Furthermore, if you simulate a crude preemptive scheduler by defining your periodic interrupt function as'
'
  (if \INTERRUPTABLE'
    then (BLOCK))'
'
you will also discover places that aren''t monitor-locked appropriately and/or assume that process switches will not occur inside code that doesn''t explicitly BLOCK. '
'
	Bill'


Workaround: 

Test Case: 

Edit-By: Sannella.PA

Edit-Date:  2-Apr-84 12':46':09

Attn: vanMelle.pa

Assigned To: 

In/By: 

Disposition: 

System: Operating System

Subsystem: Processes

Machine: 

Disk: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Difficulty: 

Frequency: Once

Impact: Minor

Priority: Perhaps

Status: Open

Problem Type: Documentation

Source Files: