Subject: AW: [clisp-list] FFI - Creating c-places in LISP? -> READ-SOME-SE QUEN CE

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Wed Oct 2 09:54:29 2002

[Ok, I'll stop replying to both individuals and the list]

Sam Steingold wrote:
>CMIIAW: if you have a regular blocking socket and you call read/write
>on it and it has _something_, it will not block.
>the only way it might block is if it has _nothing_.
>So you can use the regular CLISP buffered socket streams with the
>proposed WRITE-SEQUENCE-ONCE and READ-SEQUENCE-ONCE and use the second
>value to decide whether the next i/o will block or not.
>Alternatively you can use SOCKET-STATUS before i/o: this should be
>cheap enough because you will be doing block i/o, not byte i/o.

I think this is enough for many applications, yet possibly not for Dave's very specialized one.

I slightly disagree on a detail: the second value (of what) cannot be used to determine blocking. Having sent 1305 bytes instead of requested 10000 does not necessarily mean that an immediately succeeding read or write will block.
The false assumption is that the initial r/w would have returned a larger value otherwise.
The OS is perfectly free to return 1 on each r/w. I mean, the OS is free to cut into packets no larger than the low-level MTU and return the size of this one buffer, even if there are more buffers available that it could immediately fill.

Only select() can tell whether blocking or not will happen.

An application I have in mind would do:
A. call select()
B. for every socket indicated by select, invoke read-or-write-some. This is guaranteed to be non-blocking thanks to (my interpretation of?) select.
C. Repeat by A.

This should yield fast threaded i/o which I believe works even without blocking sockets.

This doesn't take into account the neccessity of using non-blocking to do asynchronous connect() calls.

Comments on your experience whether this actually works? Or is non-blocking behaviour nevertheless required?

Dave Richards wrote:
>Non-blocking is required to ensure that each I/O only performs what is
>possible with no delay and that the server is then available to perform
>other work.  This is what I meant by partial read()s/write()s.
I believe non-blocking is not needed if preceeded by select(). Would you like to comment?

Regards,
	Jorg Hohle.