ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: Greg.mpls@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:89760] [Ruby trunk Bug#14968] [PATCH] io.c: make all pipes nonblocking by default
Date: Thu, 08 Nov 2018 23:04:30 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-74814.20181108230429.8dabfc3b7493020a@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-14968.20180806044602@ruby-lang.org

Issue #14968 has been updated by MSP-Greg (Greg L).


@normalperson  Eric,

Sorry for the delay.  The patch passed.  I applied it to r65635...



----------------------------------------
Bug #14968: [PATCH] io.c: make all pipes nonblocking by default
https://bugs.ruby-lang.org/issues/14968#change-74814

* Author: normalperson (Eric Wong)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: 
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
Crap, I always planned to have something like this for [Feature #13618]
(auto-Fiber); but introducing a race condition for Timer-thread
elimination in [Misc #14937] forced me to introduce this early.

Anyways, I might have to revert and reintroduce timer-thread if this
change is unnacceptable :<  (I HATE timer thread)

```
io.c: make all pipes nonblocking by default

All normal Ruby IO methods (IO#read, IO#gets, IO#write, ...) are
all capable of appearing to be "blocking" when presented with a
file description with the O_NONBLOCK flag set; so there is
little risk of incompatibility within Ruby-using programs.

The biggest compatibility risk is when spawning external
programs.  As a result, stdin, stdout, and stderr are now always
made blocking before exec-family calls.

Timer-thread elimination in https://bugs.ruby-lang.org/issues/14937
introduced a race condition in signal handling.  It is possible
to receive a signal inside BLOCKING_REGION right before read/write
syscalls.  If this patch cannot be accepted, I will have to revert
to reintroduce timer-thread and increase resource use (which
led to other failures in the past).  The race condition
introduced for [Misc #14937] led to rare CI failures on a few
tests:

- test/ruby/test_thread.rb (test_thread_timer_and_interrupt):
  http://www.rubyist.net/~akr/chkbuild/debian/ruby-trunk/log/20180805T080500Z.fail.html.gz

- test/ruby/test_io.rb (test_race_gets_and_close):
  http://ci.rvm.jp/results/trunk@P895/1190369

This change is ALSO necessary to take advantage of (proposed
lightweight concurrency (aka "auto-Fiber") or any similar
proposal: https://bugs.ruby-lang.org/issues/13618

TODO: all sockets and FIFOs non-blocking by default, too
```


---Files--------------------------------
0001-io.c-make-all-pipes-nonblocking-by-default.patch (12.1 KB)


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

  parent reply	other threads:[~2018-11-08 23:04 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-14968.20180806044602@ruby-lang.org>
2018-08-06  4:46 ` [ruby-core:88305] [Ruby trunk Bug#14968] [PATCH] io.c: make all pipes nonblocking by default normalperson
2018-08-06  5:36   ` [ruby-core:88309] " Eric Wong
2018-08-06 21:12     ` [ruby-core:88314] " Eric Wong
2018-11-05 23:22   ` [ruby-core:89713] " Eric Wong
2018-12-07  7:18     ` [ruby-core:90359] " Eric Wong
2018-08-06 22:04 ` [ruby-core:88315] " Greg.mpls
2018-08-06 23:33   ` [ruby-core:88317] " Eric Wong
2018-08-07  2:44 ` [ruby-core:88319] " Greg.mpls
2018-08-07  4:07   ` [ruby-core:88320] " Eric Wong
2018-08-09  8:30 ` [ruby-core:88377] " usa
2018-08-09  8:46   ` [ruby-core:88379] " Eric Wong
2018-08-09  8:57 ` [ruby-core:88382] " usa
2018-08-10  0:48 ` [ruby-core:88405] " shyouhei
2018-08-10  2:04   ` [ruby-core:88410] " Eric Wong
2018-11-06  0:28 ` [ruby-core:89714] " Greg.mpls
2018-11-06  0:59   ` [ruby-core:89715] " Eric Wong
2018-11-06  4:14 ` [ruby-core:89717] " Greg.mpls
2018-11-08  3:35   ` [ruby-core:89755] " Eric Wong
2018-11-08 23:04 ` Greg.mpls [this message]
2018-11-22  6:12 ` [ruby-core:89950] " ko1
2018-11-22  8:55   ` [ruby-core:89963] " Eric Wong
2018-11-29 21:21   ` [ruby-core:90174] " Eric Wong
2018-11-22  9:44 ` [ruby-core:89965] " takashikkbn
2018-11-22 10:16   ` [ruby-core:89967] " Eric Wong
2018-11-22 13:07 ` [ruby-core:89971] " takashikkbn
2018-11-22 14:29 ` [ruby-core:89973] " takashikkbn
2018-11-22 15:15 ` [ruby-core:89976] " Greg.mpls
2018-11-22 15:39 ` [ruby-core:89977] " Greg.mpls
2018-11-22 20:10   ` [ruby-core:89983] " Eric Wong
2018-11-22 20:28     ` [ruby-core:89984] " Eric Wong
2018-11-22 22:59 ` [ruby-core:89990] " Greg.mpls
2018-11-23  0:41 ` [ruby-core:89993] " Greg.mpls
2018-11-23  4:39 ` [ruby-core:89997] " Greg.mpls
2018-11-24  8:43   ` [ruby-core:90030] " Eric Wong
2018-11-24 17:11 ` [ruby-core:90042] " Greg.mpls
2018-11-24 18:02 ` [ruby-core:90044] " Greg.mpls
2018-11-24 20:12   ` [ruby-core:90045] " Eric Wong
2019-06-20 23:09 ` [ruby-core:93292] " samuel
2019-06-24  1:51   ` [ruby-core:93327] " Eric Wong

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-74814.20181108230429.8dabfc3b7493020a@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).