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

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

Recommended way to handle ClosedByInterruptException?

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

Contents

  Recommended way to handle ClosedByInterruptException? raphfrk@gmail.com - 2013-01-02 18:43 -0800
    Re: Recommended way to handle ClosedByInterruptException? Knute Johnson <nospam@knutejohnson.com> - 2013-01-02 19:48 -0800
      Re: Recommended way to handle ClosedByInterruptException? raphfrk@gmail.com - 2013-01-03 13:12 -0800
        Re: Recommended way to handle ClosedByInterruptException? Knute Johnson <nospam@knutejohnson.com> - 2013-01-03 15:51 -0800

#20908 — Recommended way to handle ClosedByInterruptException?

This is an example of what causes this exception

http://hastebin.com/mayuyuvimu.avrasm

This gives:

Exception in thread "main" java.nio.channels.ClosedByInterruptException
	at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
	at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:880)
	at Main.main(Main.java:17)

----------------------

Anyway, there doesn't seem to be any sane way of dealing with this.  If interrupt is intended to mean stop what you are doing and stop the thread cleanly, then this works against that.  This prevents you doing any more writes to the file.  Is the intention that you reopen the file and then do the writes.

Also, it doesn't even clear the interrupted flag.  So, you have to wipe the flag manually if you want to repeat the write attempt.

[toc] | [next] | [standalone]

#20911

On 1/2/2013 6:43 PM, raphfrk@gmail.com wrote:
> This is an example of what causes this exception
>
> http://hastebin.com/mayuyuvimu.avrasm
>
> This gives:
>
> Exception in thread "main"
> java.nio.channels.ClosedByInterruptException at
> java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
>
>
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:880)
> at Main.main(Main.java:17)
>
> ----------------------
>
> Anyway, there doesn't seem to be any sane way of dealing with this.
> If interrupt is intended to mean stop what you are doing and stop the
> thread cleanly, then this works against that.  This prevents you
> doing any more writes to the file.  Is the intention that you reopen
> the file and then do the writes.
>
> Also, it doesn't even clear the interrupted flag.  So, you have to
> wipe the flag manually if you want to repeat the write attempt.
>

I think the intent is that interrupting a blocked file channel is an 
immediate abort, not a way to stop the thread cleanly.  From the docs on 
ClosedByInterruptException;  "Checked exception received by a thread 
when another thread interrupts it while it is blocked in an I/O 
operation upon a channel. Before this exception is thrown the channel 
will have been closed and the interrupt status of the previously-blocked 
thread will have been set."

Are you deliberately interrupting the thread or is something 
unanticipated happening?

-- 

Knute Johnson

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

#20928

The idea is to have a thread that handles the actual writing to disk.

On shutdown, the thread is interrupted.  It then writes any remaining data and then the thread dies.

However, with this, if the a .map() call is made after the interrupt, the files closes.

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

#20934

On 1/3/2013 1:12 PM, raphfrk@gmail.com wrote:
> The idea is to have a thread that handles the actual writing to
> disk.
>
> On shutdown, the thread is interrupted.  It then writes any remaining
> data and then the thread dies.
>
> However, with this, if the a .map() call is made after the interrupt,
> the files closes.
>

I think the answer is self evident then, don't interrupt it.

-- 

Knute Johnson

[toc] | [prev] | [standalone]

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

csiph-web