Subject: Re: Lisp for HTML HOWTO
From: rpw3@rigden.engr.sgi.com (Rob Warnock)
Date: 29 Aug 2001 03:55:59 GMT
Newsgroups: comp.lang.lisp
Message-ID: <9mhp4f$f0bea$1@fido.engr.sgi.com>
Jochen Schmidt  <jsc@dataheaven.de> wrote:
+---------------
| Daniel Barlow wrote:
| > Well, more likely it calls the operating system which puts your task
| > on some wait queue to be woken up at some point after an interrupt
| > comes in from the network to tell us that there's more data.  So, no
| > polling involved at all.  That makes a big performance difference.
| 
| I fear the problem is that you think polling is "looping until an I/O event 
| occurs" - but that is completely wrong - it is simply "waiting until an
| I/O event occurs"!  What you probably mean is "dummy polling" which would
| mean implementing the waiting as a simple loop.
+---------------

I fear it is you who have somwhere learned a non-standard meaning of
"polling". Classically, what you are calling "dummy polling" is in
fact what everyone else know as simply "polling" -- testing some predicate
repeatedly, as impatient children do in the car: "Are we there yet?
Are we there yet? Are we there yet...?"

It meant that as far back as 1970 (if not before), when it applied to
such things as:

- Deciding which of a number of senders on a "polled multi-drop" shared
  modem line should be granted access to send.  The master node "polled"
  each slave in turn, over & over, until one of the slaves replied with
  non-null data (instead of a "I have nothing to do" response to the poll).

  ["Hub go-ahead polling" was a variant in which each node could hear all
  the others, and thus no explicit "master" was needed, since the poll
  sequence could be implicit. When you heard the station whose sequence
  number wass just below yours say "Nothing more to send", you knew you
  could go ahead and send. Datapoint's ARCnet worked that way.]

- A scheduler for an embedded application, where continuous polling
  for each of the possible input events was sometimes much more
  efficient that allowing interrupts. [In fact, our group has written
  on-board firmware that works exactly that way quite recently.]

So polling does mean looping -- whether over one test or many -- until
(one of) the test(s) succeeds.

As another poster observed, the Unix System-V system call of that name
is *VERY* badly mis-named, since it actually doesn't "poll" at all.


-Rob

-----
Rob Warnock, 30-3-510		<rpw3@sgi.com>
SGI Network Engineering		<http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA