[#66678] [ruby-trunk - Feature #10481] Add "if" and "unless" clauses to rescue statements — alex@...
Issue #10481 has been updated by Alex Boyd.
3 messages
2014/12/04
[#66762] Re: [ruby-changes:36667] normal:r48748 (trunk): struct: avoid all O(n) behavior on access — Tanaka Akira <akr@...>
2014-12-10 0:44 GMT+09:00 normal <ko1@atdot.net>:
3 messages
2014/12/10
[#66851] [ruby-trunk - Feature #10585] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs — funny.falcon@...
Issue #10585 has been updated by Yura Sokolov.
3 messages
2014/12/15
[#67126] Ruby 2.2.0 Released — "NARUSE, Yui" <naruse@...>
We are pleased to announce the release of Ruby 2.2.0.
8 messages
2014/12/25
[#67128] Re: Ruby 2.2.0 Released
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2014/12/25
I can't install it in any of our Ubuntu servers using rbenv:
[#67129] Re: Ruby 2.2.0 Released
— SHIBATA Hiroshi <shibata.hiroshi@...>
2014/12/25
> I can't install it in any of our Ubuntu servers using rbenv:
[ruby-core:66785] [ruby-trunk - Bug #10583] Process.spawn stalls forever opening named pipes (fifo)
From:
ruby-lang.org@...
Date:
2014-12-11 18:01:56 UTC
List:
ruby-core #66785
Issue #10583 has been updated by Justin Greer.
While the reduced testcase I attached previously sounds like a rare usage, it's actually pretty common any time you're tying together multiple programs and one of them only knows how to work with a file/fifo instead of stdin/stdout. Our actual usage is more along the lines of this pattern:
~~~
fifo_path = '/path/to/data_fifo'
`mkfifo '#{fifo_path}'`
decoder_pid = Process.spawn("decode_data", "/path/to/input_file", fifo_path, :close_others => true)
filter_pid = Process.spawn("filter_data", :STDIN => fifo_path, :STDOUT => "/path/to/filtered_file", :close_others => true)
result = Process.wait2(decoder_pid)
# Handle result...
result = Process.waitpid(filter_pid)
# Handle result...
~~~
The above seems to be expected/common usage when you want to be able to monitor process status better than if it's being run by a shell. (Possibly also reading its stderr as it runs.)
I'm not sure that ignore_error really conveys the usage correctly here. Generally speaking, I would expect that the default behavior of Process.spawn matches the description of posix_spawn which it's based on. Having a version that checks for specific issues with exec seems like it should be an alternate form, maybe Process.safe_spawn or Process.spawn(..., :synchronous => true).
Either that, or it should use a non-blocking open when it tries to open files, so that the stall doesn't happen. (Then it would need to switch back to non-blocking, so it doesn't change the standard behavior for the exec'ed process.)
----------------------------------------
Bug #10583: Process.spawn stalls forever opening named pipes (fifo)
https://bugs.ruby-lang.org/issues/10583#change-50364
* Author: Justin Greer
* Status: Feedback
* Priority: Normal
* Assignee:
* Category:
* Target version:
* 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/