Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.unix.wizards
Subject: Re: Human vs. machine input (was: Re: Behaviour of setjmp/longjmp ...)
Message-ID: <36397@think.UUCP>
Date: 14 Feb 89 20:25:04 GMT
References: <25@torsqnt.UUCP> <225800127@uxe.cso.uiuc.edu> <7697@chinet.chi.il.us> <1016@auspex.UUCP>
Sender: news@think.UUCP
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 27

In article <1016@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
>None of the systems I've worked with "waste" much CPU time "watching"
>for "meaningless" transitions of the <shift> key; on Suns, for example,
>and probably on a lot of other machines, the host is interrupted when a
>key on the keyboard goes up or down, and, frankly, the keyboard driver
>is not particularly near the top of the list of functions consuming CPU
>time on a Sun.

But consider the case in an X Window System environment.  Every key
transition results in a packet being sent from the server to the
client.  This causes the client application process to be scheduled so
that it can decode the packet, notice that it was just a shift key
transition, set some state, and go back to waiting for the next
packet.

I don't deny that this is wasteful of network and cpu resources, and
NeWS probably allows improvement by moving some of these operations
into the server when the client doesn't need them.  However, X is an
important fact of life these days.

Boy, have we gotten off the subject of C!

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar