Bug #17607
closedChildProcess vs RUBY_PIPE_NONBLOCK_DEFAULT
Description
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 <top (required)>'
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 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.
Updated by vo.x (Vit Ondruch) almost 4 years ago
vo.x (Vit Ondruch) wrote:
Unfortunately, other test case started to fail then. I am not really sure what might be the right fix.
Starting from scratch again, this might be fix after all, because I can't see any issues now. Ruby as well as the ChildProcess test suites succeeds without the O_NONBLOCK
.
Updated by jeremyevans0 (Jeremy Evans) over 3 years ago
- Status changed from Open to Closed
Updated by vo.x (Vit Ondruch) over 3 years ago
- Status changed from Closed to Open
Sorry for chaos, but this is real issue. I was confused for a while, because I forgot to add the CHILDPROCESS_POSIX_SPAWN=true
to the childprocess test suite to exercise the specific branch. More details is in the chidlprocess ticket.
Updated by jeremyevans0 (Jeremy Evans) over 3 years ago
According to the ChildProcess ticket, the issue can be fixed by them switching from using four separate code paths for different operating systems and platforms to using Process.spawn
in all cases. Are you sure this is a bug in Ruby, and not their code depending on implementation-specific behavior?
Updated by vo.x (Vit Ondruch) over 3 years ago
I am sure that the behavior changed and I'd like to better understand why. Unfortunately, the analysis is beyond my knowledge. Changing Childprocess implementation might be the right solution after all, but not without understanding the issue.
Updated by jeremyevans0 (Jeremy Evans) over 3 years ago
- 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.