From: timsuth@... (Tim Sutherland) Date: 2004-03-01T20:09:46+09:00 Subject: Re: ruby-dev summary 22877-23014 In article <20040226182529P.aamine@loveruby.net>, Minero Aoki wrote: >Hi all, > >This is a summary of ruby-dev mailing list in these days. > > >[ruby-dev:22859] Re: [ruby-talk:91705] io/nonblock > > Nobuyoshi Nakada suggested new methods for nonblocking I/O: > > * IO#nonblock? > * IO#nonblock = flag > * IO#nonblocking(flag) { .... } > * IO#nonblock { .... } > * IO#nonblock > > TANAKA Akira is opposed to this idea, because: > > * Nonblocking IO is not useful in most cases. > * Nonblocking flag is inherited to child processes, > that is very dangerous. > > He also suggested alternative solution, "stdio-sensitive sysread". > > This issue is still open. [...] The Unix Socket FAQ says (http://www.developerweb.net/sock-faq/detail.php?id=16) "Not quite to do with EPROTO from read(), but I found out once that on some STREAMS-based implementations, EPROTO could be returned by accept() if the incoming connection was reset before the accept completes. On some other implementations, accept seemed to be capable of blocking if this occured. This is important, since if select() said the listening socket was readable, then you would normally expect not to block in the accept() call. The fix is, of course, to set nonblocking mode on the listening socket if you are going to use select() on it." -- Tim Sutherland 2004 SDKACM President Software Developers' Klub - the University of Auckland ACM Student Chapter http://www.sdkacm.com/