Lisp HUG Maillist Archive

non-blocking READ-SEQUENCE

When developing efficient I/O over sockets one could think that READ-SEQUENCE would be the
right thing to transfer larger chunks at a whole.

A problem that arises is that READ-SEQUENCE blocks if the peer does not send enought elements
to fill the whole (bounded) sequence.

What one would want is some kind of READ-SEQUENCE which blocks on the first element and
after that fills the sequence as long as data is available on the socket. (semantically calling READ-CHAR-NO-HANG until it returns NIL).

The good side is that with the new read-timeouts one could simulate such a thing by setting the read-timeout to 0 on the socket-stream when the "nonblocking" part is read. If one does that and uses READ-SEQUENCE the sad thing is that READ-SEQUENCE signals END-OF-FILE (like all other input functions) so that the position of the first element not filled in is not returned.

I could probably work this out by falling back to the undocumented buffering primitives again - but I think a simpler and much better solution would be to either

 a) change READ-SEQUENCE to return the position of the first element not read into the sequence on 
     timeout-triggered END-OF-FILEs (as defined in the ANSI Spec)
 b) provide a variant of READ-SEQUENCE (like CMUCLs READ-N-BYTES) which behaves this way.

ciao,
Jochen
______________________________________________________________________________
WEB.DE FreeMail wird 5 Jahre jung! Feiern Sie mit uns und
nutzen Sie die neuen Funktionen http://f.web.de/features/?mc=021130


Unable to render article 1680 because of ":DEFAULT stream decoding error on #<SB-SYS:FD-STREAM for \"socket 192.168.43.216:64863, peer: 116.202.254.214:119\" {1003250AF3}>: the octet sequence #(246 115 99 104) cannot be decoded." error

Updated at: 2020-12-10 08:58 UTC