From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-05-22T02:27:16+09:00
Subject: Re: Nonblocking socket-connect

------=_Part_184929_3963424.1148232433417
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I also prefer *_nonblock.

Based on my reading of io.c and socket.c, it seems to me that IO objects ar=
e
designed to have a strong interaction with Ruby threads. And this is really
unavoidable because, as everyone immediately points out, any green-thread
implementation is required to avoid blocking the whole process if one threa=
d
should ever make a blocking call.

As Tanaka pointed out, the need for this interaction goes away when IO
operations are strictly nonblocking. But it's really quite difficult to
write nonblocking IO in any case, not just in Ruby (you have to deal with a
plethora of platform dependencies as well as a large range of possible
errors). So I think the current implementation makes the right choice by
concentrating on working as well as possible with blocking IO.

So it seems like a good choice to provide methods for nonblocking IO (some
belong in Socket and some in IO) that are explicitly designed only for
nonblocking. That way only people who really need nonblocking IO will need
to learn them, and everyone else can ignore them.

I think that any call to a nonblocking operation should set the nonblocking
mode on the descriptor, and programmers should be warned not to mix blockin=
g
and nonblocking operations on the same descriptor (as they are warned not t=
o
mix buffered and unbuffered). An alternative is to provide a
platform-neutral IO#set_nonblock call (replacing the strange convention of
calling a Unix-style fcntl and relying on some internal magic to do the
right thing on Windows). But that doesn't solve the whole problem since you
can't tell a descriptor is nonblocking on Windows. I think nonblocking mode
should be implicitly set on any call to a *_nonblock method.

As a starting point, I'm happy to contribute the nonblocking calls that wer=
e
developed for eventmachine.

On 5/21/06, Sam Roberts <sroberts@uniserve.com> wrote:
>
> Quoting matz@ruby-lang.org, on Sun, May 21, 2006 at 11:39:21PM +0900:
> > Hi,
> >
> > In message "Re: Nonblocking socket-connect"
> >     on Sat, 20 May 2006 17:01:03 +0900, Tanaka Akira <akr@m17n.org>
> writes:
> >
> > |Do you find an acceptable name?
> > |
> > |    connect_nonblock
> > |  nbconnect
> > |    connectnb
> > |    connect!
> > |
> > |    accept_nonblock
> > |  nbaccept
> > |    acceptnb
> > |
> > |    recvfrom_nonblock
> > |  nbrecvfrom
> >
> > *_nonblock sound better than others from my POV.  Any opinion?
>
> I like the _nonblock best of the 4.
>
> > Is there any issue other than a name left?
>
> Is there a description somewhere of what they do, and why setting
> nonblock on the socket is not sufficient?
>
> Its a bit odd, usually ruby Socket methods mirror the BSD socket API
> fairly closely, I think the problem here has to do with interactions
> with threads, and ruby's implicit calling of select before making sys
> calls on a descriptor, but if there is a mailing list thread  that
> discusses the problem in more detail, or an RCR, could someone point it
> out to me?
>
> Thanks,
> Sam
>
>
>

------=_Part_184929_3963424.1148232433417--