Bug #17607: ChildProcess vs RUBY_PIPE_NONBLOCK_DEFAULT

• Status: Closed
• Assignee: -
• Target version: -
• 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

[vo.x (Vit Ondruch)]

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.

[vo.x (Vit Ondruch)]

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.

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed

[vo.x (Vit Ondruch)]

• 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.

[jeremyevans0 (Jeremy Evans)]

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?

[vo.x (Vit Ondruch)]

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.

[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.