From: merch-redmine@... Date: 2021-07-01T18:58:52+00:00 Subject: [ruby-core:104461] [Ruby master Bug#17607] ChildProcess vs RUBY_PIPE_NONBLOCK_DEFAULT Issue #17607 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed vo.x (Vit Ondruch) wrote in #note-5: > I am sure that the behavior changed and I'd like to better understand why. The behavior changed to non-blocking by default in order to support the fiber scheduler. Changing it back to blocking is likely to break parts of the fiber scheduler. That part definitely is an expected change and not a bug. I looks like ChildProcess will be updated to work with Ruby 3.0. At least there is recent activity by the maintainer indicating they like the direction in @Eregon's patch: https://github.com/enkessler/childprocess/issues/172#issuecomment-866470569 Closing since this does not appear to be a bug in Ruby. ---------------------------------------- Bug #17607: ChildProcess vs RUBY_PIPE_NONBLOCK_DEFAULT https://bugs.ruby-lang.org/issues/17607#change-92717 * Author: vo.x (Vit Ondruch) * Status: Closed * Priority: Normal * ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- I am investigating why ChildProcess test suite fails running against Ruby 3.0 [1]. The current failure is: ~~~ 1) ChildProcess can write to stdin interactively if duplex = true Failure/Error: raise msg RuntimeError: timed out after 10 seconds: expected "hello\ncat: -: Resource temporarily unavailable\n" to match /\Ahello\r?\n\z/m Diff: @@ -1,2 +1,3 @@ -/\Ahello\r?\n\z/m +hello +cat: -: Resource temporarily unavailable # ./spec/spec_helper.rb:197:in `wait_until' # ./spec/io_spec.rb:121:in `block (2 levels) in ' ~~~ and as far as I can tell, the issue is that `RUBY_PIPE_NONBLOCK_DEFAULT` in io.c, which was `0`, was changed to `O_NONBLOCK` in commit:0e3b0fcdba70cf96a8e0654eb8f50aacb8024bd4. I have tried to replace the `O_NONBLOCK` by `0` and the test succeeded. Unfortunately, other test case started to fail then. I am not really sure what might be the right fix. This might have also reintroduced the #15356. [1]: https://github.com/enkessler/childprocess/issues/173 -- https://bugs.ruby-lang.org/ Unsubscribe: