From: Wilson Bilkovich <wilsonb@...>
Date: 2008-08-02T00:44:10+09:00
Subject: [ruby-core:18054] Re: JRuby adding ConcurrencyError for fatal concurrent modification

On 7/31/08, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
> Yukihiro Matsumoto wrote:
>
> > Hi,
> >
> > In message "Re: [ruby-core:18033] JRuby adding ConcurrencyError for fatal
> concurrent modification"
> >    on Fri, 1 Aug 2008 03:26:10 +0900, Charles Oliver Nutter
> <charles.nutter@sun.com> writes:
> >
> > |In order to limit or reduce the likelihood that multiple threads
> |concurrently performing unsynchronized modifications to a shared |resource
> (like an Array, String, or Hash), we are adding a |ConcurrencyError in
> JRuby. ConcurrentError extends ThreadError, and is |primarily a debugging
> tool. The intended purpose is to prevent a Java |stack trace from being
> generated, killing the thread in question, with |no way to rescue and log
> it. This is not intended to be a |generally-recoverable error; it's more to
> say "you were concurrently |modifying something and shouldn't have been" so
> the code can be fixed.
> >
> > If ConcurrentError is supposed to be caught, I think it should not be
> > a subclass of ThreadError, which is a subclass of StandardError, that
> > is caught by rescue by default.
> >
>
>  Hmm, that's a good point. The intention with
> ConcurrentError/ConcurrencyError is more to provide a
> ruby-friendly error rather than either a Java stack trace or dumping core.
> So perhaps it shouldn't be under the StandardError hierarchy.
>

What if it were a subclass of Interrupt?  The roles seem similar to
me; each type of error can only occur in an 'environment', not in a
single-threaded script.