From: Roger Pack <rogerpack2005@...>
Date: 2009-07-21T06:45:03+09:00
Subject: Re: Thread.abort_on_exception default to true


> What do you mean by "clean up" here?  If you care about the thread
> status, you can call join, that reports the exception inside of the
> thread.

I agree that using #join here would result in cleanup that would allow 
the exception to no longer be swallowed--however I will explain my side 
of it.  Typically one uses join to mean only "wait for 
termination"--using it as cleanup has always felt surprising to me, and 
whenever I start a new multi-thread application, I am almost always 
surprised by the fact that some error messages are swallowed.

here's a (somewhat contrived) ex:

"deep within a some server: "

Thread.new { send an email }

# continue running, handle next request, etc.

In this instance, I don't want to join on the thread because I am not 
concerned about when it finishes--it doesn't matter to me, and I don't 
want to wait for it as it would slow up processing my next request. 
Therefore the exception is forgotten.


I only mention it because this just happened to me (again--this time 
while debugging someone else's code, but), it surprised me once more, 
hence my noting it here--perhaps as a compromise threads could output 
the uncaught backtrace to stderr unless #join has already been called on 
the thread?  I realize there are problems with that, too, just thinking 
for options.

Thoughts?
Thanks.
=r
-- 
Posted via http://www.ruby-forum.com/.