From: Aaron Patterson Date: 2013-07-12T02:15:27+09:00 Subject: [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 wrote: > > On Wed, Jul 10, 2013 at 09:03:19AM +0900, Eric Wong wrote: > > > "tenderlovemaking (Aaron Patterson)" 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/