Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!quanta.eng.ohio-state.edu!kcgl1.eng.ohio-state.edu!JONESD
From: JONESD@kcgl1.eng.ohio-state.edu (David Jones)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <5080@quanta.eng.ohio-state.edu>
Date: 7 Jun 90 04:08:45 GMT
References: <1990Jun6.222126.2888@midway.uchicago.edu>
Sender: news@quanta.eng.ohio-state.edu
Organization: Ohio State University
Lines: 29

gft_robert@gsbacd.uchicago.edu writes:
>In article <:SY35CD@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes...
>
>>A compiler, for example, really has no business
>>calling GetNextEvent *ever*.
>
>And if the user wants to interrupt the compilation mid-compile?  You'd better
>have some way of finding at least this out.  GetNextEvent (or WaitNextEvent)
>seems the proper way to do this to me.

Traditionally, the way this happens is that a hardware interrupt (e.g.
hitting a keyboard key) causes supervisory code to execute that monitors
the interrupts for a sequence which means "stop what you're doing".  If a
stop request is detected, the supervisory code alters the saved context of
the task to cause it's execution to cease, hopefully in a graceful manner.
In the case of most programs, including compilers, graceful rundown can
be handled by the run-time environment, so the programmer can write his
code without any conscious awareness that the user may want to interrupt it.

Do Macintosh keyboards generate interrupts (talking about hardware in
comp.arch, how strange :-)?  The software environment sure wants to behave
as if the I/O devices are strictly polled.

David L. Jones               |      Phone:    (614) 292-6929
Ohio State Unviversity       |      Internet:
1971 Neil Ave. Rm. 406       |               jonesd@kcgl1.eng.ohio-state.edu
Columbus, OH 43210           |               jones-d@eng.ohio-state.edu

Disclaimer: A repudiation of a claim.