Re: Thread.interrupt()

[Jesper Peterson <jep at esec dot com dot au>]

"Boehm, Hans" wrote:

>It seems to me that there are a bunch of problems with leaving out
>interruptable
>I/O:
>[...] 
> - The closest alternative, closing the descriptor, doesn't feel like
> reasonable programming
> practice.  If I want to stop a worker thread I created, it's not necessarily
> my business to
> know what file descriptor it's waiting on.  The "technique", if I understand
> it correctly,
> seems to be a gross violation of modularity.

Not at all. Doug Lea's approach works very well for me. In fact I have an
application that depends on it. An object extends or contains the thread,
that object holds the state of the resources and I 'cancel' via that object.

It is essential that it be possible to block on I/O and cancel at will from
another thread. Otherwise a number of interesting applications cannot be
implemented. Granted I could poll, but I'm old-fashioned, I don't waste CPU
cycles no matter how many of them there are.

-- 
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