[ruby-core:68828] [Ruby trunk - Bug #10583] [Rejected] Process.spawn stalls forever opening named pipes (fifo)

Issue #10583 has been updated by Akira Tanaka.

Status changed from Feedback to Rejected

After thinking while, I decided to reject this issue.
Invoke spawn() in a thread for this usage: Thread.new { spawn(command, :in => fifo_path) }

Accepting this issue needs spawn() use fork() system call instead of vfork() system call.
So spawn() will be slower.

fork() is slower on bigger parent process.
So Thread.new { spawn_using_vfork() } will be faster than spawn_using_fork() for big parent process.
I'm not sure the threshold, though.

Also, opening a named pipe should not block other threads.
This problem is fixed at the latest trunk.
But the fix needs opening files in the parent process. 
So it contradict this issue.




----------------------------------------
Bug #10583: Process.spawn stalls forever opening named pipes (fifo)
https://bugs.ruby-lang.org/issues/10583#change-52091

* Author: Justin Greer
* Status: Rejected
* Priority: Normal
* Assignee: 
* ruby -v: ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-darwin14.0]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
Ruby's implementation of Process.spawn seems to attempt to send error/success information from the spawned process back to the parent, and the parent won't continue until it gets this information.  However, a named pipe (fifo) is mapped to the spawned process' IO, it will stall opening the IO stream, and never be able to send the error/success status back to the parent.

While stalled, the parent process is sitting here: https://github.com/ruby/ruby/blob/ruby_2_1/process.c#L3403  This prevents spawning multiple commands that communicate through a named pipe.

Example testcase is attached.

---Files--------------------------------
spawn_bug_example.rb (486 Bytes)


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