Thread.interrupt()

Boehm, Hans hans_boehm@hp.com
Tue Mar 14 16:30:00 GMT 2000


I agree that this approach works well in some (many?) cases.  I also agree
that restarting the I/O after an interruption is unlikely to be practical.

But I'm not convinced this is a general solution.

What bothers me is the following scenario:

Thread A starts worker threads B, C, and D.

Thread B makes 27 nested method calls, each in a different class, written by
different authors.
The 28th call decides that it needs some information from a file somewhere
halfway around the world, and opens a connection to the server.  The access
access takes a long time, e.g. because the server is accessible only by 1200
baud
modem.

Threads C and D so something else using some of the same classes.

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.
It can't put it in a fixed global place, since C and D might overwrite it.

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
close will just block.  Apparently some version of Solaris do this.  Before
this discussion,
that would have seemed like the obvious, safe implementation to me.  Thus
I'd be
surprised if this behavior occurred only in Solaris.

Hans
 
-----Original Message-----
From: Jesper Peterson [ mailto:jep@esec.com.au ]
Sent: Tuesday, March 14, 2000 3:59 PM
To: java-discuss@sourceware.cygnus.com
Subject: Re: Thread.interrupt()


"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


More information about the Java mailing list