Thread.interrupt()

Tue Mar 14 16:09:00 GMT 2000

>> 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.
>> Well, according to the JDK 1.2 API docs, it does for socket reads. We don't
> implement this properly yet, though.
>> public void setSoTimeout(int timeout)
> throws SocketException
>
I implemented both InterruptedIOException and the socket timeout stuff
in Kaffe a while ago. You could use SoInterrupt.java and SoTimeout.java
from the regression directory if you need test cases.
I tend to agree with Lea's (or whoever's) argument that a meaningful 
continuation after an interrupted I/O is rarely possible. IIRC, the
argument he gave was that the interruption will often occur deep inside
a layered hierarchy of BufferReader/StreamReader/Reader etc. which cannot
deal with interrupted I/O. One issue is that you may end up with 
partial reads/writes after an interruption, which need to be dealt with.
In other words, the buffer classes would have to be interruption-aware
and "restartable". Otherwise, data may be sent or received twice.
Granted, these classes could be fixed, but at a higher cost in 
implementation complexity. For this reason, I think that the more 
pragmatic "close-the-socket" approach may be preferable.
	- Godmar