I want interrupts from things that occur rarely or infrequently
and from things for which I am waiting.   I am quite happy to
poll for things that are normally waiting for me.

At the dentist,  I am in a collection of waiting patients.   I
expect to be allowed to read or gaze out of the window or chat
and be interrupted by  "Please come in now,  Mr. Irish".   On
the other hand,  the dentist polls for the next patient by
examining the collection of waiting patients and uttering the
words  "Please come in now,  Mr. Irish".

As far as computers are concerned,  I am under the impression
that word processors spend most of their time waiting for human
keystrokes.   So,  I want them to be designed to treat human
keystrokes as interrupts.   On the other hand,  when asked to
open an existing file and display some part of it on the
screen,  I expect them to poll for the next character.

Of course,  it is really much more complicated than that.
Although the highest level logic may poll for the next
character,  lower down logic knows about buffers.   When the end

of a buffer is reached,  the lower down logic has to ask
something for another buffer's worth of characters.   That may
take quite a time,  after all it may be coming from New Zealand
or the moon,  so I want the lower down logic not to poll for
arriving buffers but to ask for an interrupt on buffer arrival.

The telephone interrupts me.   Some days I have no calls.   Some

days I have one or two calls.   Occasionally,  I have more
calls.   My landline telephone is designed for interrupts
only.   It cannot be polled.   Interestingly  (well,  I think it

is interesting),  my mobile telephone is much more
sophisticated.   It can interrupt me and I can select,  from a
short list,  the sound it makes.   When it is called,  the
display lights up,  so,  by turning off the sound and glancing
at the display from time to time  (probably about four times a
minute)  I can poll it.   But it is even better than that.   If
it is turned off when called or I do not answer a call,  a
computer plays a recording of my voice,  followed by one of its
voice  (going on about re-recording a message),  records a
message from the caller if they have not hung up first and,
finally,  puts an icon on the display,  so that next time I look

at it,  I know that it has taken a message.   It is a sort of
automatic buffering system.   The last bit is not actually
terribly clever because if the caller waits long enough for it
to start recording and then hangs up,  it is not smart enough to

realise that no message has been left and I waste time and money

ringing up to listen to nothing.

Personally,  I operate on a mixture of interrupts and polling.
I work in a school and have a long list of things to do,  some
of which do not get done for months and even years.   I have an
in tray collection and a pending tray collection  (things I have

started but not finished).   I would say that,  in general,  I
polled for my next activity.   Sometimes in conjunction with
other people and sometimes alone,  I review the two collections
in the light of ever changing criteria to decide what to do
now.   The criteria change in importance both in relationship to

each other and in relationship to the real world.   To a limited

extent other people add things to my in tray collection.
Mostly,  however,  they interrupt me to ask me to add things to
my in tray collection.   Some such things have  "do it now or
forget it"  priority.

I think it is useful to think of two sorts of interrupt.   The
sort where you want to drop everything and deal with it at once
and the sort where you merely acknowledge its occurrence and put

it to one side to be dealt with later.   Waiting for the dentist

and buffer arrival are examples of the first sort.   Adding
things to my in tray collection and human keystrokes are
examples of the second sort.   On computers,  I favour the use
of circular buffers for the second sort to avoid buffer
overflow.

It is very important to be able to deal with interrupts fast
enough.   If you cannot deal with them fast enough there is no
point in bothering with them at all.   Historically,  few
programs were required to run in real time.   Now,  it is my
impression that,  increasingly,  programs are being required to
run in real time.

An additional complication is that some interrupt streams
address more than one part of the system.   For instance,  human

keystrokes do.   Ordinary letters and digits are for the
application.   <Control + c>  is for the Squeak system,  a user
interrupt  (according to the Orange book,  anyway).   <Control +

Alt + Del>,  in a Microsoft Windows environment,  is for the
operating system,  a user interrupt.   Either of the user
interrupts needs immediate response.   I should like an
application to be able to define its own interrupt  "control
characters".   Similar considerations apply to mice.

The Blue book mentions hardware interrupts in the context of
"three Semaphores"  corresponding  "to three Processes
monitoring user events,  the millisecond clock and memory
utilization."   (I,  of course,  spell it utilisation;  two
nations divided by a common language,  and all that.)   It seems

to lump human keystrokes and mouse activity together.   I rather

incline to the view that they are better separated.   I am
doubtful that hardware interrupts had anything to do with  "low
space"  notification.

My conclusion is that,  although I stand by the first paragraph
of this e-mail and am in favour of Squeak providing interrupt
facilities,  the question of whether to use interrupts or
polling is a tactical one whose answer depends on the
circumstances,  as is normal in life,  even though,  at times,
the circumstances may be bizarre,  historical or of no obvious
relevance.

--
Michael Irish    Wednesday 23 August 2000


--
Michael  Irish