Nonblocking socket-connect

Hi,

In message "Re: Nonblocking socket-connect"
    on Tue, 16 May 2006 00:42:39 +0900, "Francis
Cianfrocca" <garbagecat10gmail.com> writes:

|Well, it's ok then. I'm comfortable adding in the
nonblocking
|functions as an extension in my asynchronous-IO framework.
If you
|decide it's best to leave nonblocking i/o out of the core,
then people
|will be able to get it if necessary through my
"eventmachine" library.

Note that I'm not against for non-blocking connect.  I just
oppose to
general purpose non-blocking attribute for IO.  Hint: name,
name.

							matz.

How about Socket#nbconnect and Socket#nbaccept?

On 5/15/06, Yukihiro Matsumoto <matzruby-lang.org> wrote:
> Hi,
>
> In message "Re: Nonblocking socket-connect"
>     on Tue, 16 May 2006 00:42:39 +0900, "Francis
Cianfrocca" <garbagecat10gmail.com> writes:
>
> |Well, it's ok then. I'm comfortable adding in the
nonblocking
> |functions as an extension in my asynchronous-IO
framework. If you
> |decide it's best to leave nonblocking i/o out of the
core, then people
> |will be able to get it if necessary through my
"eventmachine" library.
>
> Note that I'm not against for non-blocking connect.  I
just oppose to
> general purpose non-blocking attribute for IO.  Hint:
name, name.
>
>                                                        
matz.
>
>

On 5/15/06, Francis Cianfrocca <garbagecat10gmail.com> wrote:
> How about Socket#nbconnect and Socket#nbaccept?

   I don't know the usual meaning of the exclamation mark,
but I think
it would be nice to use it in order to separate blocking
routines from
their non-blocking counterparts. Since usually the
exclamation mark
suggests impatience, I thought that socket.connect! would be
quite
appropriate to express the idea "connect now or
else!", where "else"
may as well mean return with an error. The same thing would
be nice
for other I/O routines too.

  My $0.02. Comments ?


>
> On 5/15/06, Yukihiro Matsumoto <matzruby-lang.org> wrote:
> > Hi,
> >
> > In message "Re: Nonblocking
socket-connect"
> >     on Tue, 16 May 2006 00:42:39 +0900,
"Francis Cianfrocca" <garbagecat10gmail.com> writes:
> >
> > |Well, it's ok then. I'm comfortable adding in
the nonblocking
> > |functions as an extension in my asynchronous-IO
framework. If you
> > |decide it's best to leave nonblocking i/o out of
the core, then people
> > |will be able to get it if necessary through my
"eventmachine" library.
> >
> > Note that I'm not against for non-blocking
connect.  I just oppose to
> > general purpose non-blocking attribute for IO. 
Hint: name, name.
> >
> >                                                   
     matz.
> >
> >
>
>


-- 
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.

My opinion only, but when I see bang at the end of a method
name, it makes
me think that it will result in some possibly dangerous
change to the object
itself, rather than urgency.

Earlier I proposed Socket#nbconnect and TCPServer#nbaccept
and
Socket#nbrecvfrom (I think these are ones that are most
needed, the rest can
be done with sysread and syswrite. Not sure yet about
datagram sends.) This
proposal has the advantage that it makes sense in English
(read "nbaccept"
as "nonblocking accept") but the potential
disadvantage that the methods
will bunch up together in alphabetical lists. Another
possibility would be
to add "nb" as a suffix: acceptnb, connectnb,
etc.

On 5/17/06, Vlad GALU <vladgalugmail.com> wrote:
>
> On 5/15/06, Francis Cianfrocca <garbagecat10gmail.com> wrote:
> > How about Socket#nbconnect and Socket#nbaccept?
>
>    I don't know the usual meaning of the exclamation
mark, but I think
> it would be nice to use it in order to separate
blocking routines from
> their non-blocking counterparts. Since usually the
exclamation mark
> suggests impatience, I thought that socket.connect!
would be quite
> appropriate to express the idea "connect now or
else!", where "else"
> may as well mean return with an error. The same thing
would be nice
> for other I/O routines too.
>
>   My $0.02. Comments ?
>
>
> >
> > On 5/15/06, Yukihiro Matsumoto <matzruby-lang.org> wrote:
> > > Hi,
> > >
> > > In message "Re: Nonblocking
socket-connect"
> > >     on Tue, 16 May 2006 00:42:39 +0900,
"Francis Cianfrocca" <
> garbagecat10gmail.com> writes:
> > >
> > > |Well, it's ok then. I'm comfortable adding
in the nonblocking
> > > |functions as an extension in my
asynchronous-IO framework. If you
> > > |decide it's best to leave nonblocking i/o
out of the core, then
> people
> > > |will be able to get it if necessary through
my "eventmachine"
> library.
> > >
> > > Note that I'm not against for non-blocking
connect.  I just oppose to
> > > general purpose non-blocking attribute for
IO.  Hint: name, name.
> > >
> > >                                              
          matz.
> > >
> > >
> >
> >
>
>
> --
> If it's there, and you can see it, it's real.
> If it's not there, and you can see it, it's virtual.
> If it's there, and you can't see it, it's
transparent.
> If it's not there, and you can't see it, you erased
it.
>
>

On 5/17/06, Francis Cianfrocca <garbagecat10gmail.com> wrote:
> My opinion only, but when I see bang at the end of a
method name, it makes
> me think that it will result in some possibly dangerous
change to the object
> itself, rather than urgency.
>
> Earlier I proposed Socket#nbconnect and
TCPServer#nbaccept and
> Socket#nbrecvfrom (I think these are ones that are most
needed, the rest can
> be done with sysread and syswrite. Not sure yet about
datagram sends.) This
> proposal has the advantage that it makes sense in
English (read "nbaccept"
> as "nonblocking accept") but the potential
disadvantage that the methods
> will bunch up together in alphabetical lists. Another
possibility would be
> to add "nb" as a suffix: acceptnb,
connectnb, etc.

#accept_nonblock, #connect_nonblock, and #recvfrom_nonblock
would be
good choices in my opinion.

They're clear that they're for nonblocking behaviour.

-austin
-- 
Austin Ziegler * halostatuegmail.com
               * Alternate: austinhalostatue.ca

On May 17, 2006, at 4:13 AM, Vlad GALU wrote:

> On 5/15/06, Francis Cianfrocca <garbagecat10gmail.com> wrote:
>> How about Socket#nbconnect and Socket#nbaccept?
>
>  don't know the usual meaning of the exclamation mark,
but I think
> it would be nice to use it in order to separate
blocking routines from
> their non-blocking counterparts. Since usually the
exclamation mark
> suggests impatience, I thought that socket.connect!
would be quite
> appropriate to express the idea "connect now or
else!", where "else"
> may as well mean return with an error. The same thing
would be nice
> for other I/O routines too.

In ruby the ! usually means the method modifies the receiver
where  
the non-bang returns a new object.  I can't think of an
example where  
the ! signifies impatience in ruby.

-- 
Eric Hodel - drbrainsegment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotco
op.com

On Thu, 18 May 2006, Eric Hodel wrote:

> On May 17, 2006, at 4:13 AM, Vlad GALU wrote:
>
>> On 5/15/06, Francis Cianfrocca <garbagecat10gmail.com> wrote:
>>> How about Socket#nbconnect and Socket#nbaccept?
>> 
>>  don't know the usual meaning of the exclamation
mark, but I think
>> it would be nice to use it in order to separate
blocking routines from
>> their non-blocking counterparts. Since usually the
exclamation mark
>> suggests impatience, I thought that socket.connect!
would be quite
>> appropriate to express the idea "connect now
or else!", where "else"
>> may as well mean return with an error. The same
thing would be nice
>> for other I/O routines too.
>
> In ruby the ! usually means the method modifies the
receiver where the 
> non-bang returns a new object.  I can't think of an
example where the ! 
> signifies impatience in ruby.

exit!

-a
-- 
be kind whenever possible... it is always possible.
- h.h. the 14th dali lama

In article <1147709691.180288.28647.nullmailerx31.priv.netlab.jp>,
  Yukihiro Matsumoto <matzruby-lang.org> writes:

> Note that I'm not against for non-blocking connect.  I
just oppose to
> general purpose non-blocking attribute for IO.  Hint:
name, name.

Do you find an acceptable name?

    connect_nonblock 
  nbconnect
    connectnb
    connect!

    accept_nonblock
  nbaccept
    acceptnb

    recvfrom_nonblock
  nbrecvfrom
-- 
Tanaka Akira

Hi,

In message "Re: Nonblocking socket-connect"
    on Sat, 20 May 2006 17:01:03 +0900, Tanaka Akira
<akrm17n.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?
Is there any issue other than a name left?

							matz.

Quoting matzruby-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
<akrm17n.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