[#7872] Nonblocking socket-connect — "Francis Cianfrocca" <garbagecat10@...>

All, I needed a nonblocking socket connect for my asynchronous-event

18 messages 2006/05/14
[#7873] Re: Nonblocking socket-connect — Tanaka Akira <akr@...17n.org> 2006/05/14

In article <3a94cf510605140559l7baa0205le341dac4f47d424b@mail.gmail.com>,

[#7874] Re: Nonblocking socket-connect — "Francis Cianfrocca" <garbagecat10@...> 2006/05/15

How about introducing the method Socket#set_nonblocking, or alternatively

[#7875] Re: Nonblocking socket-connect — Yukihiro Matsumoto <matz@...> 2006/05/15

Hi,

[#7876] Re: Nonblocking socket-connect — "Francis Cianfrocca" <garbagecat10@...> 2006/05/15

Well, it's ok then. I'm comfortable adding in the nonblocking

[#7877] Re: Nonblocking socket-connect — Yukihiro Matsumoto <matz@...> 2006/05/15

Hi,

Re: Nonblocking socket-connect

From: "Vlad GALU" <vladgalu@...>
Date: 2006-05-17 11:13:53 UTC
List: ruby-core #7890
On 5/15/06, Francis Cianfrocca <garbagecat10@gmail.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 <matz@ruby-lang.org> wrote:
> > Hi,
> >
> > In message "Re: Nonblocking socket-connect"
> >     on Tue, 16 May 2006 00:42:39 +0900, "Francis Cianfrocca" <garbagecat10@gmail.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.


In This Thread