Documenting Thread#raise, Thread#kill, and timeout.rb as unsafe

Please refer to https://www.ruby-forum.com/topic/143840 for background.
The consensus in that thread appears to be that Thread#raise,
Thread#kill, and timeout.rb are unsafe.

Aside from the issue of providing safe alternatives, would it not be a
great service to the Ruby community, especially newcomers, to document
this lack of safety in the relevant classes?

If such documentation is thought to be worthwhile and we can agree on
suitable wording, I will happily submit a pull request.

Here’s a first draft of the wording:

Warning: this method can produce unpredictable behaviour and its use

is not recommended.

See https://www.ruby-forum.com/topic/143840 for more information.

Thread from 2008?

Seriously ruby was in 1.8 at the time. Ruby has check and wall already
implemented as well as a bug trac system

On Thu, Sep 12, 2013 at 1:08 AM, Glyn Normington
[email protected]wrote:

Please refer to https://www.ruby-forum.com/topic/143840 for background.
The consensus in that thread appears to be that Thread#raise,
Thread#kill, and timeout.rb are unsafe.

Yes, they are unsafe. Ruby 2.0 has done some work to try to improve
their
safety at the cost of performance, but they are still unsafe on other
Ruby
VMs, particularly those without a GIL, and are probably still buggy on
Ruby
2.0 as well.

Aside from the issue of providing safe alternatives, would it not be a

great service to the Ruby community, especially newcomers, to document
this lack of safety in the relevant classes?

Considering the work that has gone into features like
Thread.handle_interrupt, ruby-core is probably unlikely to accept such a
label, although it would probably make sense.

Thanks Tony.

I think the difficulty with Thread.handle_interrupt is that it, or
something similar, would need to be used correctly across Ruby’s class
libraries, e.g. in the networking classes, in order for Thread#raise,
thread#kill and timeout.rb to be safe for general use. I couldn’t see
any evidence of such activity in the last couple of years in
https://github.com/ruby/ruby, although maybe I was unlucky in my search.
Perhaps the majority of the libraries had already been written with
timeout.rb’s limitations in mind, but it’s hard to know.

But I take the point that the blanket warning is not likely to be
acceptable.

Yes, Stu, I know this is an old problem, but that doesn’t necessarily
mean it has been fixed. I’m relatively new to Ruby and just trying to
work out how much to trust it.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs