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.
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.
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.
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?
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.
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.
Updated by 
Updated by