Volkan YAZICI  <volkan.yazici@gmail.com> wrote:
+---------------
| On Nov 5, 4:45 am, r...@rpw3.org (Rob Warnock) wrote:
| > What I would do instead in this case is write your own version
| > of READ-SEQUENCE which uses whatever underlying "select()/poll()"
| > calls [or equiv.] intermingled with native "read()"s (which will
| > be non-blocking if you only issue one when the "select()/poll()"
| > says there's something there [though if you're really paranoid
| > you might want to do an FIONREAD "ioctl()" or equiv. to be sure]),
| > so that the timeouts *only* ever occur during the "select()/poll()"
| > calls. In that case, you'll have a deterministic count of "amount
| > already read".
| 
| How about using WAIT-FOR-INPUT with a TIMEOUT value in USOCKET[1]?
| [1] http://common-lisp.net/project/usocket/
+---------------

Uh... AFAICT that just gives you a "select()/poll()" with timeout
[which is how (WAIT-FOR-INPUT ... :TIMEOUT ...) is likely to be
implemented in current OSs], exactly as I suggested above.
You still need to do a non-blocking read and then wrap a loop
around pairs of "WAIT-FOR-INPUT"s & read"s to effect the full
semantics of READ-SEQUENCE. [AFACT USOCKET doesn't support a
:TIMEOUT arg to READ-SEQUENCE. But see Duane Rettig's parallel
reply re the extensions Allegro has to READ-SEQUENCE...]

+---------------
| Moreover, as a bonus, you get compatibility availability between
| different Common Lisp implementations.
+---------------

Well, those that support USOCKET... ;-}


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607