Thread.interrupt()

Tue Mar 14 17:17:00 GMT 2000

"Boehm, Hans" wrote:
>[...]
> Thread A decides it wants to cancel thread B. How can it close the file
> descriptor,
> which is located in a local variable 28 frames down in B's stack? Even if B
> cooperated,
> and put the file descriptor in some public place, there's no obvious place
> to put it.

Fair enough, it isn't a general solution and I definitely agree that
Thread.interrupt() is far preferable. The discussion so far was suggesting
that interruptable I/O had been given up for dead, and I wanted to point
out that at least one of interuptable I/O or resource revocation (preferably
both) *must* work. If neither works GCJ or Java generally would not be very
useful to me.
What I really need is for Thread.interrupt() to work, and an atomic
readIfNotInterrupted() so a single interrupt is guaranteed to make a thread
fall through a read() or alternatively make Thread.destroy() work.
I need to be able to cancel a thread that does this: while(!done){read()}
even if the read blocks. Resource revocation does this very nicely for
the specific code that I am working on.
>The second problem, apparent from the Sun bug report, is that this approach
>fails if
>the underlying close and read implementation each acquire the same lock,
>since the

I would expect the underlying implementation to not hold the lock while
waiting for I/O. If the underlying platform is badly implemented either
for threads, I/O or both I would not expect Java applications that use
these semantics to work. Disallowing it just because there is at least
one platform where it will not work opens up a can of worms. There will
always be some platform that cannot properly implement a given behaviour,
the product of all platforms will probably disallow all useful behaviours.
-- 
Jesper Peterson - Are my methods unsound?
Senior Software Developer - I don't see any method at all Sir.
eSec Limited --- Apocalypse Now
http://www.esec.com.au