
[BOR]
0: Safe
1: Please only post links to actual news sources, no tabloid sites, etc
2: No NSFW content
3: No hate speech, bigotry, propaganda, etc

[EOR]
[BOC]
i don't believe anyone has asked for Timeout to be 'fixed' in the OP or in this thread. 

Although, actually, it _was_ improved with regard to these issues in ruby 2.0. I'm not sure how well the additional interrupt control tools work, I'd never heard of them until this thread and haven't tried them. But apparently someone in ruby core agreed it was difficult to use Timeout correctly prior to 2.0, and thought it was possible to improve things. Ruby core committer Koichi Sasada agrees that interupts in ensure blocks are a problem, disagreeing with you. https://bugs.ruby-lang.org/issues/6762   Ruby core team was a lot less defensive than you are being, they didn't try to convince everyone that there was nothing to worry about and improvements would be useless. koi wrote: "Thank you for addressing this issue. ensure clause behaving properly is most important to me."

Anyhow, the issue is that Timeout used in a lot of code by people who don't understand or don't realize the impact of it's extreme limitations, so education is needed. 

I knew how Timeout works; I've still used it in places I shouldn't, and had to go back and debug mysterious bugs.  So I needed some education too. I think probably almost everyone who has used Timeout has used it without fully thinking through the ramifications of ensure blocks being no longer guaranteed to run. Multi-threaded concurrency can be tricky, and as soon as you use Timeout.timeout, you're doing concurrent programming. 

Worse, gem writers may not realize the issue, and suggest Timeout use with their gems in an unsafe way, or avoid providing a save 'timeout' argument (which is needed with ALL I/O code to avoid the possibility of your code hanging forever on I/O), figuring that wrapping with a Timeout.timeout is good enough. I agree with the OP that as a general rule, I/O operations ought to provide their own timeouts, in safe ways often using timeouts in the underlying C libraries where possible, or else with ruby stdlib Timeout in very carefully audited and tested isolated code -- not rely on the user of the gem to wrap in a Timeout.timeout. Even some of the stdlib does not do this however. 

Many people have made Timeout-related concurrency errors, including experienced skilled programmers, the mongo adapter issue was another example, where mongo adapter was _not_ safe to be used in a timeout, but clients were encouraged to wrap it in a timeout.  https://jira.mongodb.org/browse/RUBY-473  

I am confident the errors will keep coming. But yes, this is how Timeout works. The solutions are: educate people on the dangers of timeout; make sure low-level timeouts from C libraries are exposed in ruby API's; investigate those newer ruby 2.0 interrupt control features, I dont' know enough about them to speak to them, they haven't gotten much coverage in English language blogs, but maybe need more too. The first two of those is what the OP recommends. 

If in your defensiveness you're trying to convince people that they don't need to pay any attention to the very dangerous concurrent nature of Timeout.timeout, you are not doing them a service. 

PS: The documenttation for ruby 2.0+ Thread.handle_interupt even uses protecting your ensure block from Timeout as an example. I need to experiment with it, never heard of it before this thread, but maybe what we really need is more education on wrapping your ensure blocks in handle_interupt, which also suggests to me maybe they ought to be by default. http://ruby-doc.org/core-2.0.0/Thread.html#method-c-handle_interrupt
[EOC]
