[#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: "Francis Cianfrocca" <garbagecat10@...>
Date: 2006-05-15 11:20:12 UTC
List: ruby-core #7874
How about introducing the method Socket#set_nonblocking, or alternatively
Socket#blocking( boolean)? A call to Socket#blocking( true ) would
*explicitly* change the behavior of calls like #connect, #accept, #read and
#write. It would still be possible for programmers to say:
    require 'fcntl'
    m = socket.fcntl(Fcntl::F_GETFL, 0)
    socket.fcntl(Fcntl::F_SETFL, Fcntl::O_NONBLOCK | m)
but this code would preserve the behavior that exists today. (That is, it
would affect the behavior of syswrite and sysread, but not of read, write,
connect, and accept).

In other words, if we call Socket#nonblocking(true), the behavior of
Socket#connect would change to a pure nonblocking behavior. But it would not
break any existing code, nor would it introduce of ugly new method names
(connect_nonblocking, read_nonblocking, write_nonblocking). Calling
Socket#nonblocking( false ) would revert to the original behavior.

On 5/14/06, Tanaka Akira <akr@m17n.org> wrote:
>
> In article <3a94cf510605140559l7baa0205le341dac4f47d424b@mail.gmail.com>,
>   "Francis Cianfrocca" <garbagecat10@gmail.com> writes:
>
> > All, I needed a nonblocking socket connect for my asynchronous-event
> > framework, and I notice that ruby_connect blocks the calling thread with
> > wait_connectable. I solved my problem with this (eliding some
> error-checking
> > and platform-specific branches):
> >
> > static VALUE
> > sock_connect_nonblocking (self, addr)
> >         VALUE self, addr;
> > {
>
> I think it's good idea to introduce new nonblocking methods.
> However no one propose a method name matz accept, yet.
> --
> Tanaka Akira
>
>

In This Thread