ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
* [ruby-core:69131] [Ruby trunk - Feature #11139] [Open] [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
       [not found] <redmine.issue-11139.20150512001411@ruby-lang.org>
@ 2015-05-12  0:14 ` normalperson
  2015-05-12  0:25 ` [ruby-core:69133] [Ruby trunk - Feature #11139] " djberg96
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 10+ messages in thread
From: normalperson @ 2015-05-12  0:14 UTC (permalink / raw)
  To: ruby-core

Issue #11139 has been reported by Eric Wong.

----------------------------------------
Feature #11139: [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
https://bugs.ruby-lang.org/issues/11139

* Author: Eric Wong
* Status: Open
* Priority: Normal
* Assignee: Akira Tanaka
----------------------------------------
[PATCH 2/2] socket: accept_nonblock supports "nonblock: false" kwarg

An application wanting to do non-blocking accept may want to create a
blocking accepted socket, allow it with a kwarg while preserving default
behavior.

If this patch is accepted, I'd also like to support the opposite
for blocking accept calls:

	a = s.accept(nonblock: true) # blocking accept syscall
	a.nonblock? # => true
	s.nonblock? # => false

This requires the simple patch in [Feature #11138]

I'm unsure if ":nonblock" is a good keyword to use, since it is
somewhat confusing


---Files--------------------------------
0002-socket-accept_nonblock-supports-nonblock-false-kwarg.patch (2.94 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:69133] [Ruby trunk - Feature #11139] [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
       [not found] <redmine.issue-11139.20150512001411@ruby-lang.org>
  2015-05-12  0:14 ` [ruby-core:69131] [Ruby trunk - Feature #11139] [Open] [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg normalperson
@ 2015-05-12  0:25 ` djberg96
  2015-05-12  0:58   ` [ruby-core:69136] " Eric Wong
  2015-06-14 10:09 ` [ruby-core:69576] [Ruby trunk - Feature #11139] [Feedback] " akr
                   ` (4 subsequent siblings)
  6 siblings, 1 reply; 10+ messages in thread
From: djberg96 @ 2015-05-12  0:25 UTC (permalink / raw)
  To: ruby-core

Issue #11139 has been updated by Daniel Berger.


How about just :block ?

    a.accept(block: false)
    a.accept_nonblock(block: true)

----------------------------------------
Feature #11139: [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
https://bugs.ruby-lang.org/issues/11139#change-52382

* Author: Eric Wong
* Status: Open
* Priority: Normal
* Assignee: Akira Tanaka
----------------------------------------
[PATCH 2/2] socket: accept_nonblock supports "nonblock: false" kwarg

An application wanting to do non-blocking accept may want to create a
blocking accepted socket, allow it with a kwarg while preserving default
behavior.

If this patch is accepted, I'd also like to support the opposite
for blocking accept calls:

	a = s.accept(nonblock: true) # blocking accept syscall
	a.nonblock? # => true
	s.nonblock? # => false

This requires the simple patch in [Feature #11138]

I'm unsure if ":nonblock" is a good keyword to use, since it is
somewhat confusing


---Files--------------------------------
0002-socket-accept_nonblock-supports-nonblock-false-kwarg.patch (2.94 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:69136] Re: [Ruby trunk - Feature #11139] [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
  2015-05-12  0:25 ` [ruby-core:69133] [Ruby trunk - Feature #11139] " djberg96
@ 2015-05-12  0:58   ` Eric Wong
  0 siblings, 0 replies; 10+ messages in thread
From: Eric Wong @ 2015-05-12  0:58 UTC (permalink / raw)
  To: Ruby developers

djberg96@gmail.com wrote:
> How about just :block ?
> 
>     a.accept(block: false)
>     a.accept_nonblock(block: true)

I don't think that helps convey it affects the newly-accepted socket,
not the socket performing the accept.  Perhaps :sock_nonblock is better,
at least it maps to SOCK_NONBLOCK in Linux.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:69576] [Ruby trunk - Feature #11139] [Feedback] [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
       [not found] <redmine.issue-11139.20150512001411@ruby-lang.org>
  2015-05-12  0:14 ` [ruby-core:69131] [Ruby trunk - Feature #11139] [Open] [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg normalperson
  2015-05-12  0:25 ` [ruby-core:69133] [Ruby trunk - Feature #11139] " djberg96
@ 2015-06-14 10:09 ` akr
  2015-06-15 23:40   ` [ruby-core:69594] " Eric Wong
  2015-06-16  1:53 ` [ruby-core:69598] [Ruby trunk - Feature #11139] " akr
                   ` (3 subsequent siblings)
  6 siblings, 1 reply; 10+ messages in thread
From: akr @ 2015-06-14 10:09 UTC (permalink / raw)
  To: ruby-core

Issue #11139 has been updated by Akira Tanaka.

Status changed from Open to Feedback

The status of nonblocking flag is not so important in Ruby
because most methods works regardless of the flag.
(Nonblocking methods sets the flag internally.  Blocking methods retry on EAGAIN/EWOULDBLOCK internally.)

So the proposed kwarg is almost no-op at Ruby level.
It may reduce system calls, though.

I'm not sure the kwarg is worth enough to provide at Ruby level.
But, if it is provided, it should have descriptive name.
"nonblock" and "block" is too short.

----------------------------------------
Feature #11139: [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
https://bugs.ruby-lang.org/issues/11139#change-52916

* Author: Eric Wong
* Status: Feedback
* Priority: Normal
* Assignee: Akira Tanaka
----------------------------------------
[PATCH 2/2] socket: accept_nonblock supports "nonblock: false" kwarg

An application wanting to do non-blocking accept may want to create a
blocking accepted socket, allow it with a kwarg while preserving default
behavior.

If this patch is accepted, I'd also like to support the opposite
for blocking accept calls:

	a = s.accept(nonblock: true) # blocking accept syscall
	a.nonblock? # => true
	s.nonblock? # => false

This requires the simple patch in [Feature #11138]

I'm unsure if ":nonblock" is a good keyword to use, since it is
somewhat confusing


---Files--------------------------------
0002-socket-accept_nonblock-supports-nonblock-false-kwarg.patch (2.94 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:69594] Re: [Ruby trunk - Feature #11139] [Feedback] [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
  2015-06-14 10:09 ` [ruby-core:69576] [Ruby trunk - Feature #11139] [Feedback] " akr
@ 2015-06-15 23:40   ` Eric Wong
  0 siblings, 0 replies; 10+ messages in thread
From: Eric Wong @ 2015-06-15 23:40 UTC (permalink / raw)
  To: Ruby developers

akr@fsij.org wrote:
> So the proposed kwarg is almost no-op at Ruby level.

Agree.

> It may reduce system calls, though.

Yes.  Also, real blocking send/recv family calls without select/ppoll
allows for exclusive "wake-one" behavior to avoid thundering herds on
wakeup.

Because there is no thundering herd, exclusive wakeup also improves
fairness if multiple threads/processes share the socket for packetized
I/O

> I'm not sure the kwarg is worth enough to provide at Ruby level.
> But, if it is provided, it should have descriptive name.
> "nonblock" and "block" is too short.

Perhaps "sock_nonblock" to match the Linux flag name? (SOCK_NONBLOCK)

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:69598] [Ruby trunk - Feature #11139] [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
       [not found] <redmine.issue-11139.20150512001411@ruby-lang.org>
                   ` (2 preceding siblings ...)
  2015-06-14 10:09 ` [ruby-core:69576] [Ruby trunk - Feature #11139] [Feedback] " akr
@ 2015-06-16  1:53 ` akr
  2015-06-16  3:35 ` [ruby-core:69600] " akr
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 10+ messages in thread
From: akr @ 2015-06-16  1:53 UTC (permalink / raw)
  To: ruby-core

Issue #11139 has been updated by Akira Tanaka.


"sock_nonblock kwarg is similar to SOCK_NONBLOCK flag in (future) POSIX" seems intuitive.

Note that accept4 (and its behavior with SOCK_NONBLOCK) will be defined in POSIX (or SUS):
http://austingroupbugs.net/view.php?id=411

It means that O_NONBLOCK flag of the created FD is set if sock_nonblock is true and
O_NONBLOCK flag is unset if sock_nonblock is false.

The behavior should work on the platforms which doesn't have accept4().
Be careful that O_NONBLOCK behavior of accept() is not portable.
http://cr.yp.to/docs/unixport.html

It is not clear that the behavior when sock_nonblock kwarg is not specified.
I feel that it should be defined anyway.
It may reduce the portability problem a bit.


----------------------------------------
Feature #11139: [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
https://bugs.ruby-lang.org/issues/11139#change-52940

* Author: Eric Wong
* Status: Feedback
* Priority: Normal
* Assignee: Akira Tanaka
----------------------------------------
[PATCH 2/2] socket: accept_nonblock supports "nonblock: false" kwarg

An application wanting to do non-blocking accept may want to create a
blocking accepted socket, allow it with a kwarg while preserving default
behavior.

If this patch is accepted, I'd also like to support the opposite
for blocking accept calls:

	a = s.accept(nonblock: true) # blocking accept syscall
	a.nonblock? # => true
	s.nonblock? # => false

This requires the simple patch in [Feature #11138]

I'm unsure if ":nonblock" is a good keyword to use, since it is
somewhat confusing


---Files--------------------------------
0002-socket-accept_nonblock-supports-nonblock-false-kwarg.patch (2.94 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:69600] [Ruby trunk - Feature #11139] [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
       [not found] <redmine.issue-11139.20150512001411@ruby-lang.org>
                   ` (3 preceding siblings ...)
  2015-06-16  1:53 ` [ruby-core:69598] [Ruby trunk - Feature #11139] " akr
@ 2015-06-16  3:35 ` akr
  2015-06-22 19:36   ` [ruby-core:69703] " Eric Wong
  2015-06-25  2:29 ` [ruby-core:69733] " akr
  2015-07-02  1:30 ` [ruby-core:69835] [Ruby trunk - Feature #11139] [PATCH] socket: support accept `sock_nonblock: (true|false)' normalperson
  6 siblings, 1 reply; 10+ messages in thread
From: akr @ 2015-06-16  3:35 UTC (permalink / raw)
  To: ruby-core

Issue #11139 has been updated by Akira Tanaka.


Akira Tanaka wrote:

> It is not clear that the behavior when sock_nonblock kwarg is not specified.
> I feel that it should be defined anyway.
> It may reduce the portability problem a bit.

"sock_nonblock: false" would be better for the default behavior.
It will reduce system calls: it avoids poll() for each blocking read operations and it adds only one fcntl(F_SETFL) for the first nonblocking operation.
It is consistent with accept4().


----------------------------------------
Feature #11139: [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
https://bugs.ruby-lang.org/issues/11139#change-52941

* Author: Eric Wong
* Status: Feedback
* Priority: Normal
* Assignee: Akira Tanaka
----------------------------------------
[PATCH 2/2] socket: accept_nonblock supports "nonblock: false" kwarg

An application wanting to do non-blocking accept may want to create a
blocking accepted socket, allow it with a kwarg while preserving default
behavior.

If this patch is accepted, I'd also like to support the opposite
for blocking accept calls:

	a = s.accept(nonblock: true) # blocking accept syscall
	a.nonblock? # => true
	s.nonblock? # => false

This requires the simple patch in [Feature #11138]

I'm unsure if ":nonblock" is a good keyword to use, since it is
somewhat confusing


---Files--------------------------------
0002-socket-accept_nonblock-supports-nonblock-false-kwarg.patch (2.94 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:69703] Re: [Ruby trunk - Feature #11139] [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
  2015-06-16  3:35 ` [ruby-core:69600] " akr
@ 2015-06-22 19:36   ` Eric Wong
  0 siblings, 0 replies; 10+ messages in thread
From: Eric Wong @ 2015-06-22 19:36 UTC (permalink / raw)
  To: Ruby developers

I don't think the flag matters for second-tier OSes, as the underlying
descriptor does not matter with our current APIs.

So better to leave the OS default if sock_nonblock kwarg is not
specified.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:69733] [Ruby trunk - Feature #11139] [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
       [not found] <redmine.issue-11139.20150512001411@ruby-lang.org>
                   ` (4 preceding siblings ...)
  2015-06-16  3:35 ` [ruby-core:69600] " akr
@ 2015-06-25  2:29 ` akr
  2015-07-02  1:30 ` [ruby-core:69835] [Ruby trunk - Feature #11139] [PATCH] socket: support accept `sock_nonblock: (true|false)' normalperson
  6 siblings, 0 replies; 10+ messages in thread
From: akr @ 2015-06-25  2:29 UTC (permalink / raw)
  To: ruby-core

Issue #11139 has been updated by Akira Tanaka.


The default behavior of accept4() is fine.

Although most Ruby-level API is nonblocking flag insensitive,
there is nonblocking flag sensitive API such as IO#syswrite.
Also, the flag affects other (non-Ruby) programs when the FD is inherited to them.
Especially stdio doesn't work well on FD with nonblocking flag.

I think setting or clearing nonblocking flag after accept() reduces unexpected behaviors.

----------------------------------------
Feature #11139: [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
https://bugs.ruby-lang.org/issues/11139#change-53115

* Author: Eric Wong
* Status: Feedback
* Priority: Normal
* Assignee: Akira Tanaka
----------------------------------------
[PATCH 2/2] socket: accept_nonblock supports "nonblock: false" kwarg

An application wanting to do non-blocking accept may want to create a
blocking accepted socket, allow it with a kwarg while preserving default
behavior.

If this patch is accepted, I'd also like to support the opposite
for blocking accept calls:

	a = s.accept(nonblock: true) # blocking accept syscall
	a.nonblock? # => true
	s.nonblock? # => false

This requires the simple patch in [Feature #11138]

I'm unsure if ":nonblock" is a good keyword to use, since it is
somewhat confusing


---Files--------------------------------
0002-socket-accept_nonblock-supports-nonblock-false-kwarg.patch (2.94 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:69835] [Ruby trunk - Feature #11139] [PATCH] socket: support accept `sock_nonblock: (true|false)'
       [not found] <redmine.issue-11139.20150512001411@ruby-lang.org>
                   ` (5 preceding siblings ...)
  2015-06-25  2:29 ` [ruby-core:69733] " akr
@ 2015-07-02  1:30 ` normalperson
  6 siblings, 0 replies; 10+ messages in thread
From: normalperson @ 2015-07-02  1:30 UTC (permalink / raw)
  To: ruby-core

Issue #11139 has been updated by Eric Wong.

File socket-support-accept-sock_nonblock-true-false-v2.patch added
Subject changed from [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg to [PATCH] socket: support accept `sock_nonblock: (true|false)'
Description updated

I think we need to preserve existing behavior with accept_nonblock in case
there is code which shares accepted FDs with non-Ruby processes (or even
passes it to a C extension).


----------------------------------------
Feature #11139: [PATCH] socket: support accept `sock_nonblock: (true|false)'
https://bugs.ruby-lang.org/issues/11139#change-53233

* Author: Eric Wong
* Status: Feedback
* Priority: Normal
* Assignee: Akira Tanaka
----------------------------------------
An application wanting to do non-blocking accept may want to
create a blocking accepted socket, allow it with a kwarg while
preserving default behavior.

This is analogous to the SOCK_NONBLOCK flag in the Linux `accept4'
syscall.

While this has little obvious effect for Ruby API users (which
can emulate blocking behavior) this will reduce syscalls made
internally by Ruby.  Forcing blocking will preserve "wake-one"
behavior in the OS kernel to avoid a "thundering herd" problem.

In all cases, existing Ruby 2.2 behavior is preserved by default
to maximize compatibility, especially when sharing sockets with
non-Ruby processes:

`accept' and `sysaccept' calls will create sockets which are
blocking by default.

`accept_nonblock', calls will create sockets which are non-blocking
by default.


---Files--------------------------------
0002-socket-accept_nonblock-supports-nonblock-false-kwarg.patch (2.94 KB)
socket-support-accept-sock_nonblock-true-false-v2.patch (20.8 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2015-07-02  1:05 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <redmine.issue-11139.20150512001411@ruby-lang.org>
2015-05-12  0:14 ` [ruby-core:69131] [Ruby trunk - Feature #11139] [Open] [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg normalperson
2015-05-12  0:25 ` [ruby-core:69133] [Ruby trunk - Feature #11139] " djberg96
2015-05-12  0:58   ` [ruby-core:69136] " Eric Wong
2015-06-14 10:09 ` [ruby-core:69576] [Ruby trunk - Feature #11139] [Feedback] " akr
2015-06-15 23:40   ` [ruby-core:69594] " Eric Wong
2015-06-16  1:53 ` [ruby-core:69598] [Ruby trunk - Feature #11139] " akr
2015-06-16  3:35 ` [ruby-core:69600] " akr
2015-06-22 19:36   ` [ruby-core:69703] " Eric Wong
2015-06-25  2:29 ` [ruby-core:69733] " akr
2015-07-02  1:30 ` [ruby-core:69835] [Ruby trunk - Feature #11139] [PATCH] socket: support accept `sock_nonblock: (true|false)' normalperson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).