From: akr@fsij.org
To: ruby-core@ruby-lang.org
Subject: [ruby-core:69598] [Ruby trunk - Feature #11139] [PATCH] socket: accept_nonblock supports "nonblock: false" kwarg
Date: Tue, 16 Jun 2015 01:53:27 +0000 [thread overview]
Message-ID: <redmine.journal-52940.20150616015326.f415f0839b3559d2@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-11139.20150512001411@ruby-lang.org
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/
next prev parent reply other threads:[~2015-06-16 1:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 ` akr [this message]
2015-06-16 3:35 ` [ruby-core:69600] [Ruby trunk - Feature #11139] " 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-52940.20150616015326.f415f0839b3559d2@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).