[ruby-core:55954] Re: [ruby-trunk - Feature #5138] Add nonblocking IO that does not use exceptions for EOF and EWOULDBLOCK

On Wed, Jul 10, 2013 at 10:52:26AM +0900, Eric Wong wrote:
> Aaron Patterson <[e-mail]> wrote:
> > On Wed, Jul 10, 2013 at 09:03:19AM +0900, Eric Wong wrote:
> > > "tenderlovemaking (Aaron Patterson)" <[e-mail]> wrote:
> > > > As for Erlang style return values.  It seems interesting, but that
> > > > means every call to `try_read_nonblock` would allocate an array.  The
> > > > only possible return values would be:
> > > 
> > > I prefer to avoid the requirement for allocating _anything_ in the
> > > common case.  So "no" to the tuple retvals.
> > > 
> > > How about making the destination buffer a required argument,
> > 
> > Does this mean someone would have to pre-allocate the buffer?  For
> > example, the "buffer" variable below would need to be defined as:
> > 
> >   buffer = " " * maxlen
> 
> Yes, but it could just be:   buffer = ""
> 
> Ruby will internally resize the string and won't waste memory
> bandwidth prefilling it with 0x20
> 
> > > and returning:
> > > 
> > > 	Integer           - length in bytes on successful read
> > > 	Symbol            - :wait_readable/:wait_writable (common)
> > > 	nil               - EOF
> > 
> > Is this really advantageous over:
> > 
> >  	String            - the buffer read in
> >  	Symbol            - :wait_readable/:wait_writable (common)
> >  	nil               - EOF
> > 
> > Length of bytes can be derived from buffer length.
> 
> It would force developers to think about buffer reuse (which helps a lot
> with big copy loops).  Otherwise, it won't help for for apps which
> already reuse buffers.

It occurs to me that this is pretty similar to IO#readpartial.  The main
difference being that readpartial automatically retries on EWOULDBLOCK
and raises an EOF error.  Maybe there should be a `try_readpartial` in
addition to the proposed `try_read_nonblock`?

WDYT?

-- 
Aaron Patterson
http://tenderlovemaking.com/