[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Modification to LISTEN
- To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
- Subject: Modification to LISTEN
- From: Mike McMahon <MMcM@SCRC-STONY-BROOK.ARPA>
- Date: Wed, 18 Sep 85 21:22 EDT
- Cc: robbins@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
- In-reply-to: <FAHLMAN.12144268018.BABYL@C.CS.CMU.EDU>
Date: Wed, 18 Sep 1985 12:56 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I would like to have LISTEN return two values. The first value is the same as
it is now and the second value is true if end of file is encountered. The
new definition allows READ-CHAR-NO-HANG to be implemented using only READ-CHAR
Looks like a good suggestion to me. It could be implemented in a
completely upward-compatible way.
In good lisp machine style, programs use both READ-CHAR-NO-HANG and
LISTEN. LISTEN is treated only as a (possibly spurious) wakeup.
Imagine a network stream interface, where LISTEN returns when some
packet-ready-for-reciept hardware flag gets set. READ-CHAR-NO-HANG
might return NIL if the packet that it reads out is damaged, out of
sequence, etc. The rule is that LISTEN is allowed to return T when
READ-CHAR-NO-HANG will return NIL, provided that READ-CHAR-NO-HANG will
tend to clear the spurious condition.
I'm not sure this advocates against the above proposal, but I do feel
that there is good reason for having both primitives.