Issue #14143 has been updated by shevegen (Robert A. Heiler).


I have too little experience with threads to meaningfully comment on this.

But I have used Thread-methods before, in particular in ruby-gtk.

I distinctly remember having had to set:

    Thread.abort_on_exception = true

in some of the .rb files.

I do not remember 100% as to why but I believe it was because if I
would not do so, I would not be able to see which error caused the
ruby GUI app to crash. Or it was somewhere hidden.

For short code it was simple to see what was going on but I found
that the more complex the widgets become, the harder it is to 
debug them (another reason why I try to write as simple as code
as possible, when I can get away with it).

After I did so, and read up on Threads, I understand it to some
extent so that I can use it just fine. But initially when I first
noticed problems, I had no real idea what was going on. It should
also be said that the ruby-gtk stuff uses some kind of internal
main loop as well, which I think has somehow to do again with
threads (in glib; my apologies for this bad description here but
I really do not know much about threads; I only know that glib
has its own loop e. g.:

    GLib::MainLoop.new(GLib::MainContext.default, true)
)

So to me, that first initial step, to find out how to deal with
threads in Ruby, was not trivial to find out. In that context
I agree with Benoit's comment "Nobody should have to remember"
which I think is a fine statement, in particular by people who
are new to ruby. It's not so difficult for more experienced,
older ruby people but for newcomers, making threads as simple
as possible would be good, IMO. (I still have not really looked
into fibers and mutexes ... it all seems to be a huge chunk of
domain-specific knowledge here to have to learn :D ).


----------------------------------------
Feature #14143: Thread.report_on_exception should be true by default
https://bugs.ruby-lang.org/issues/14143#change-68079

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
Extracted from #6647 to focus on the default value now that the feature is implemented.

I strongly believe we should have Thread.report_on_exception = true by default.

It only adds some extra stderr output for apps which let threads die, which is very rarely intended.
If it is intended, then one can use Thread.current.report_on_exception = false
to clarify it's OK for that thread to die and the failure is handled by the app on Thread#join.

I enabled Thread.report_on_exception=true by default in ruby/spec, see https://github.com/ruby/spec/pull/517,
the only cases needing Thread.current.report_on_exception=false
are the specs testing report_on_exception itself and Thread#join/value/status/raise.

Enabling it for test-all shows a fair amount of extra output and failures, which I would bet some of them are bugs in the tests (I already found one, r60854 & r60870),
and other tests should simply more carefully test what they expect
(for instance assert_raise() inside the Thread just around the code raising an exception and join the Thread).

I am willing to help to reduce the extra output and failures in test-all,
but I would like a OK from Matz to try enabling Thread.report_on_exception by default.

Dear Matz, do you think it is reasonable to show exceptions killing threads on stderr by default,
instead of silently swallowing them until Thread#join ?
(if there is ever a Thread#join ..., often not or too late, when the rest of the application has crashed)



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

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>