[#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: "Austin Ziegler" <halostatue@...>
Date: 2006-05-17 13:07:35 UTC
List: ruby-core #7894
On 5/17/06, Francis Cianfrocca <garbagecat10@gmail.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 * halostatue@gmail.com
               * Alternate: austin@halostatue.ca


In This Thread