Re: read/write-sequeqnce-no-hang

[Sam S. <sd...@gn...>]

> * In message <161...@is...>
> * On the subject of "Re: read/write-sequeqnce-no-hang"
> * Sent on Thu, 31 Jul 2003 19:57:18 -0700
> * Honorable don...@is... (Don Cohen) writes:
>
>  > > Whatever became of this idea?
>  > > I expect it would be a big win for applications that want to do a
>  > > lot of IO without blocking.
>  > 
>  > READ-BYTE-SEQUENCE accepts :NO-HANG argument since 2003-01-24.
> Great, that's half the problem solved.
> 
>  > WRITE-BYTE-SEQUENCE would need much work - you are welcome to do
>  > it.
> (Perhaps you'll realize before you've answered many of my questions
> that you could have already more easily implemented what I want!)

I consider this a good investment.

> I notice in sequence.d the only mention of no-hang (I didn't actually
> expect any) is a question of what to return.  This is clearly not the
> bottleneck.  You could easily return a second value of position like
> the value of read-sequence.

write-sequence is an ANSI function and cannot return additional values.
write-byte-sequence is less constrained, of course, except by
consistency considerations.

> I notice there's a separate case for 8 bit bytes.  Is this expected to
> be much faster?  I'm guessing and hoping so since that's probably the
> most common case and the one I care about.

yes, this is the only case where the i/o is done in batch.

> It looks like read functions have nohang args "all the way down" and
> write functions don't.  I suppose that's the reason write is not done
> already.

yes, up to full_read() which uses read_helper().
there is no write_helper() which could be used by full_write().

note that read_helper() and full_write() are exported in
bindings/linuxlibc6/linux.lisp, so you will need to modify it when you
add write_helper().

> I see low level function calls in the read functions -
> ls_avail_p - is there any analog for writing?

no, and that is another big problem.

> I also worry about the cost of this checking.  All of this is not
> going to be a big win if the cost is similar to doing a bunch of calls
> to listen/listen-byte/read-byte-will-hang-p which all seem to have
> cost similar to socket-status (which is what I use now on each byte).

at low level (like low_write_array() &c) you can use better
functionality, i.e., write_helper().

> It occurs to me that a very cheap approximation that would be adequate
> for me is something that deals only with internal lisp buffers.  It
> seems clear that there will be no blocking if the operation will
> simply get or put a byte from/to a lisp buffer.  Only when the buffer
> is empty/full is there any danger.  So if I could do a read- or write-
> sequence that stops when the buffer is empty/full it would be very
> fast for a limited number of bytes.  Then I could do the socket-status
> for the expensive case.  Would this be easy to implement and as
> efficient as I hope?

I am not sure what you mean.
yes, you can fill CLISP buffers fast (no i/o there).
suppose the buffer is 4k (because it is :-).
suppose you do SOCKET-STATUS before flushing and it says that :OUT is
permitted.  this does not mean that you can flush the buffers all at
once because the socket might be prepared to accept only 2k.
but you can flush them part way - with write_helper().

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Our business is run on trust.  We trust you will pay in advance.