Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #18909 > unrolled thread

Interrupted exception chaining

Back to article view | Back to comp.lang.java.programmer

Contents

  Interrupted exception chaining raphfrk@gmail.com - 2012-09-25 03:25 -0700
    Re: Interrupted exception chaining Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-25 08:56 -0400
    Re: Interrupted exception chaining markspace <-@.> - 2012-09-25 08:33 -0700
      Re: Interrupted exception chaining Ivan Ryan <ivan.ryan@gmail.com> - 2012-09-25 09:28 -0700
        Re: Interrupted exception chaining Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-25 13:12 -0400
        Re: Interrupted exception chaining markspace <-@.> - 2012-09-25 12:00 -0700
    Re: Interrupted exception chaining Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-09-25 09:22 -0700
      Re: Interrupted exception chaining Jan Burse <janburse@fastmail.fm> - 2012-09-25 22:26 +0200
        Re: Interrupted exception chaining markspace <-@.> - 2012-09-25 13:37 -0700
          Re: Interrupted exception chaining Jan Burse <janburse@fastmail.fm> - 2012-09-25 22:47 +0200
            Re: Interrupted exception chaining Jan Burse <janburse@fastmail.fm> - 2012-09-25 22:53 +0200
              Re: Interrupted exception chaining Jan Burse <janburse@fastmail.fm> - 2012-09-25 22:53 +0200
            Re: Interrupted exception chaining markspace <-@.> - 2012-09-25 14:08 -0700
              Re: Interrupted exception chaining Jan Burse <janburse@fastmail.fm> - 2012-09-25 23:23 +0200
                Re: Interrupted exception chaining Jan Burse <janburse@fastmail.fm> - 2012-09-25 23:24 +0200
                Re: Interrupted exception chaining Jan Burse <janburse@fastmail.fm> - 2012-09-25 23:32 +0200
              Re: Interrupted exception chaining Jan Burse <janburse@fastmail.fm> - 2012-09-25 23:42 +0200
                Re: Interrupted exception chaining Jan Burse <janburse@fastmail.fm> - 2012-09-25 23:48 +0200
                Re: Interrupted exception chaining Jan Burse <janburse@fastmail.fm> - 2012-09-25 23:55 +0200
                  Re: Interrupted exception chaining markspace <-@.> - 2012-09-25 15:33 -0700
        Re: Interrupted exception chaining Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-25 21:43 -0400
    Re: Interrupted exception chaining Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-09-26 01:43 +0200
      Re: Interrupted exception chaining Jan Burse <janburse@fastmail.fm> - 2012-09-26 10:24 +0200
        Re: Interrupted exception chaining Jan Burse <janburse@fastmail.fm> - 2012-09-26 10:32 +0200
          Re: Interrupted exception chaining Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-09-26 16:26 +0200

Page 2 of 2 — ← Prev page 1 [2]

#18935

On 9/25/2012 4:26 PM, Jan Burse wrote:
> Hi,
>
> Daniel Pitts schrieb:
>> Do you really have a use-case for uninterruptableWait? Perhaps you
>> should instead have a different approach to interrupting that thread. An
>> interrupt is often a result of a user-action, and ignoring it will make
>> users mad.  It may also be the case that the interrupt was caused
>> because something else failed, and waiting no longer is useful.
>
> Since he calls Thread.currentThread().interrupt() the next
> wait() will throw an InterruptedException.

     "The next wait()" is a re-execution of the first wait().
It is re-called *before* Thread.currentThread().interrupt(),
and will therefore *not* throw an InterruptedException until
and unless some other thread calls interrupt().

> But the biggest flaw I see in the original code, is that
> done=true is not called in the exception handler, so it will
> not break out of the code. Actually it will inflict a new
> InterruptedException by the wait() and so on.

     Ah!  So your diagnosis above is not about the O.P.'s code
at all, but about an undisclosed modification you have imagined.
Fine: Feel free to debug your own imagination.  (Start with the
"will inflict" part, because AFAICS no such thing will happen.)

> (Erics and marks code have a similar flaw, the flaw there
> is that wait() is again called, so code could block)

     Both markspace and I pointed out that the O.P.'s code is
fundamentally flawed.  My rewrite solved the question as asked,
while preserving the original flaw; markspace's addressed it
in a slightly different way, still preserving the flaw.  I think
it hardly fair to blame me and markspace for the flaw we both
carefully preserved (and pointed out).

> Probably the code is only working, since wait()s are allowed
> to be spurious. But if this is not happening the CPU will
> burn, burn, burn, ...

     This the first time I have encountered "spurious" in the
description of a *call* to wait().  It is known that a *return*
from wait() may be "spurious" in the sense that it can occur
without a notify() or notifyAll() or interrupt(), but in what
sense can the *call* be "spurious?"

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#18934

On 25/09/2012 12:25, raphfrk@gmail.com allegedly wrote:
> Is there a recommended way of "chaining" interrupted exceptions?
> 
> This is to implement a method call that doesn't throw an interrupted exception, but which calls a method which can be interrupted.
> 
> public void uninterruptableWait(Object c) {
>     boolean done = false;
>     boolean interrupted = false;
>     synchronized (c) {
>         while (!done) {
>             try {
>                 c.wait();
>                 done = true;
>             } catch (InterrupedException ie) {
>                 interrupted = true;
>             }
>         }
>     }
>     if (interrupted) {
>         Thread.currentThread().interrupt();
>     }
> }
> 
> If that interrupt was unexpected, and causes a stack trace, then it would be nice if it could include the details from the thrown exception.
> 
> Is there a better way to do the above?

a) When catching an InterruptedException, always, always call
Thread.currentThread().interrupt() in the catch block. Always. Unless
you know what you're doing.

b) If you want a stacktrace, just print a stacktrace. Like, in the catch
block. But note that by definition, interruptedness is a state, not an
action. The only thing a stacktrace will tell you is where in the code
that state was /checked/, not where it was /set/.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#18939

Daniele Futtorovic schrieb:
> a) When catching an InterruptedException, always, always call
> Thread.currentThread().interrupt() in the catch block. Always. Unless
> you know what you're doing.

No

[toc] | [prev] | [next] | [standalone]

#18940

Jan Burse schrieb:
>> a) When catching an InterruptedException, always, always call
>> Thread.currentThread().interrupt() in the catch block. Always. Unless
>> you know what you're doing.
>
> No

Mh, yes. Catch it at the right moment, outside your loop.
And yes Thread.currentThread().interrupt() isn't the worst.

And don't forget all your I/O can also be interrupted, so
you have to watch as well the following exception:

	InterruptedIOException
	http://docs.oracle.com/javase/1.4.2/docs/api/java/io/InterruptedIOException.html

But it usually goes unrecognized or ripples down, since
it is a subclass of IOException. Also the bytesTransferred
doesn't work well, especially if the stream is wrapped.

Bye

[toc] | [prev] | [next] | [standalone]

#18945

On 26/09/2012 10:32, Jan Burse allegedly wrote:
> Jan Burse schrieb:
>>> a) When catching an InterruptedException, always, always call
>>> Thread.currentThread().interrupt() in the catch block. Always. Unless
>>> you know what you're doing.
>>
>> No
> 
> Mh, yes. Catch it at the right moment, outside your loop.
> And yes Thread.currentThread().interrupt() isn't the worst.
> 
> And don't forget all your I/O can also be interrupted, so
> you have to watch as well the following exception:
> 
>     InterruptedIOException
>     http://docs.oracle.com/javase/1.4.2/docs/api/java/io/InterruptedIOException.html
> 
> 
> But it usually goes unrecognized or ripples down, since
> it is a subclass of IOException. Also the bytesTransferred
> doesn't work well, especially if the stream is wrapped.

The point, which I believe you're missing, is that when you catch the
InterruptedException, the thread's interrupted status is _cleared_.
Normally, you don't want to lose that information (to wit, that it's
been interrupted). Unless, again, you specifically know what you're
doing. But since in my experience the overwhelming majority of
developers, even the experienced ones, are unaware of this fact, I
reckon it warrants a little vehemence.

-- 
DF.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web