🚀 go-pugleaf

In article <2793@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>By the way, why hasn't anyone jumped all over the silly claim that
>multitasking would get rid of event loops?  Event loops are an intrinsic
>part of a modern graphical interface, as opposed to prompt-driven programs.
>There are only two ways to program these interfaces: explicit event loops,
>or a hidden (in the OS) event loop that calls event-handling routines
>supplied by the programmer.  Either can be implemented with or without
>multi-tasking, either pre-emptive or not.

Waaaaaaait a minuite.  If I/O is interrupt driven, and the tasker has
an 'active' and an 'idle' process queue, 'idle' processes are completely
out of the loop until the interrupt routine puts it on the active queue
once I/O is complete.  Now I don't know if this is exactly what the Amiga
does, but I can certainly envision a scheme that dosen't involve explicit
'event' loops.
 
And as far as graphical user interfaces, if the keyboard is interrupt driven,
and the mouse is interrupt driven, how is that any different from prompt-
driven interfaces?  You don't move the mouse, don't hit the keyboard,
NO PENALTY.  It's as if they aren't even there.  The task waiting for
a mouse or keyboard click is sitting on the idle queue out of the task
loop until the interrupt routine moves it to the active queue.

Unless you are considering the tasker itself as an 'event' loop, in 
which case it has nothing to do with graphical vs prompt interfaces.

Keith Doyle
#  {ucbvax,decvax}!trwrb!cadovax!keithd
#  cadovax!keithd@ucla-locus.arpa  Contel Business Systems 213-323-8170