Re: [clisp-list] Re: READ-SEQUENCE-NO-HANG

[Arseny S. <am...@ic...>]

Hello Sam,

Friday, October 04, 2002, 11:32:47 PM, you wrote:

> We already have READ-CHAR-NO-HANG and READ-BYTE-NO-HANG, so, I think,
> READ-SEQUENCE-NO-HANG is the right name, if we really need it.

>> select() does not tell you how many bytes of input you can read, or
>> how many bytes you can write, without blocking. Thus if you want to
>> avoid blocking, you have to read() or write() the bytes one by one,
>> which damages performance if there is not a computation intensive
>> counterpart on the Lisp side.
>> 
>> Therefore most Unices offer the ability to put a socket or file
>> descriptor into non-blocking mode.

> So why not add FIONBIO to SOCKET-OPTIONS and let the users call that
> before READ-SEQUENCE?

> (Arseny said that FIONBIO will break some things - which ones?)

At least you should then check for [WSA]EWOULDBLOCK error in all reads
and writes. send() also can return less than data length supplied.
Maybe there is something else, need to look into the code. I'm just
saying it's not enough just to put a socket in nonblocking mode - need
to check all the code to handle it (FIXME).

Next, to get rid of WSACancelBlockingCall I wanted to make all sockets
nonblocking and emulate blocking with select() loops. It is possible
(FIXME).

So maybe make a socket-stream option BLOCKING and use it in that
select loops and in READ-SEQUENCE ?

Advantages:
1. can be queried (AFAIK blocking mode of socket can't be checked)
  so READ-SEQUENCE can determine how to behave.
2. Lowlevel code handling just one socket mode, simpler.
3. no WSACancelBlockingCall.

-- 
Best regards,
 Arseny