RE: Thread.interrupt()

[Miles Sabin <msabin@cromwellmedia.co.uk>]

Jeff Sturm wrote,
> IOW, Sun crippled their API because Win32 doesn't handle 
> interruptable I/O portably.  Not a good policy.
>
> Since Java doesn't support read() with timeouts either, it is 
> easy to create a "stuck" thread that can never die.

The following posting of Doug Lea's on this topic from a while 
back on the advanced-java list is the best response to your
complaint ...

Doug Lea wrote,
> I think the consensus is that Interruptible I/O was a
> reasonable-looking notion that turned out to be a bad idea in
> practice. In fact, I hope it becomes deprecated before it is 
> fully implemented. (Currently, it is very incompletely 
> implemented, at least on Solaris and Win platforms.) The 
> fundamental problem is that there is rarely a reasonable 
> continuation action that can be taken if low-level I/O 
> interrupts.  Most Java programs use buffered or translated 
> I/O classes, which in turn rely on lower-level I/O classes. 
> But there is hardly ever a way for them to roll back or
> forward under a lower level exception. So the only recourse 
> is to abort.
>
> Given this (see http://gee.cs.oswego.edu/dl/cpj/cancel.html ), 
> usually the best way to implement cancellation in I/O is just 
> resource revocation -- asynchronously forcibly closing the 
> stream that the thread is operating on. This results in a 
> generic I/O exception, which can then be used to shut down a 
> thread. This works well (at least on Solaris 1.2. I don't 
> know about other platforms). To play it safe, and force 
> termination whether the thread is actually doing any I/O, you
> should normally do both stream.close() and Thread.interrupt
> ().

Cheers,


Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
msabin@cromwellmedia.com          http://www.cromwellmedia.com/