public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Boehm, Hans" <hans_boehm@hp.com>
To: "'Jesper Peterson'" <jep@esec.com.au>,
	java-discuss@sourceware.cygnus.com
Subject: RE: Thread.interrupt()
Date: Tue, 14 Mar 2000 16:30:00 -0000	[thread overview]
Message-ID: <140D21516EC2D3119EE700902787664456E6FA@hplex1.hpl.hp.com> (raw)

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

WARNING: multiple messages have this Message-ID
From: "Boehm, Hans" <hans_boehm@hp.com>
To: "'Jesper Peterson'" <jep@esec.com.au>,
	java-discuss@sourceware.cygnus.com
Subject: RE: Thread.interrupt()
Date: Sat, 01 Apr 2000 00:00:00 -0000	[thread overview]
Message-ID: <140D21516EC2D3119EE700902787664456E6FA@hplex1.hpl.hp.com> (raw)
Message-ID: <20000401000000.qtesBQZTsGG-92_49uRlGdr2RsTiPyXYfiHQlGtjPsw@z> (raw)

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

             reply	other threads:[~2000-03-14 16:30 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-14 16:30 Boehm, Hans [this message]
2000-03-14 17:17 ` Thread.interrupt() Jesper Peterson
2000-03-14 17:27   ` Thread.interrupt() Tom Tromey
2000-04-01  0:00     ` Thread.interrupt() Tom Tromey
2000-04-01  0:00   ` Thread.interrupt() Jesper Peterson
2000-04-01  0:00 ` Thread.interrupt() Boehm, Hans
  -- strict thread matches above, loose matches on Subject: below --
2000-04-01  0:00 Thread.interrupt() Bryce McKinlay
2000-03-13 13:33 ` Thread.interrupt() Bryce McKinlay
2000-03-14  2:24   ` Thread.interrupt() Kresten Krab Thorup
2000-03-14  3:26     ` Thread.interrupt() Bryce McKinlay
2000-04-01  0:00       ` Thread.interrupt() Bryce McKinlay
2000-03-14  5:52     ` Thread.interrupt() Jeff Sturm
2000-03-14 11:02       ` Thread.interrupt() Tom Tromey
2000-04-01  0:00         ` Thread.interrupt() Tom Tromey
2000-03-14 14:16       ` Thread.interrupt() Bryce McKinlay
2000-03-14 16:09         ` Thread.interrupt() Godmar Back
2000-04-01  0:00           ` Thread.interrupt() Godmar Back
2000-04-01  0:00         ` Thread.interrupt() Bryce McKinlay
2000-04-01  0:00       ` Thread.interrupt() Jeff Sturm
2000-04-01  0:00     ` Thread.interrupt() Kresten Krab Thorup
2000-04-01  0:00   ` Thread.interrupt() Bryce McKinlay
2000-03-16  4:08 Thread.interrupt() Miles Sabin
2000-04-01  0:00 ` Thread.interrupt() Miles Sabin
2000-03-15 13:52 Thread.interrupt() Boehm, Hans
2000-04-01  0:00 ` Thread.interrupt() Boehm, Hans
2000-03-15 13:06 Thread.interrupt() Miles Sabin
2000-04-01  0:00 ` Thread.interrupt() Miles Sabin
2000-03-15 12:55 Thread.interrupt() Boehm, Hans
2000-04-01  0:00 ` Thread.interrupt() Boehm, Hans
2000-03-15 11:57 Thread.interrupt() Miles Sabin
2000-04-01  0:00 ` Thread.interrupt() Miles Sabin
2000-03-15 11:38 Thread.interrupt() Boehm, Hans
2000-04-01  0:00 ` Thread.interrupt() Boehm, Hans
2000-03-15  5:51 Thread.interrupt() Miles Sabin
2000-04-01  0:00 ` Thread.interrupt() Miles Sabin
2000-03-14 11:26 Thread.interrupt() Boehm, Hans
2000-04-01  0:00 ` Thread.interrupt() Boehm, Hans
2000-03-14  9:57 Thread.interrupt() Boehm, Hans
2000-03-14 10:52 ` Thread.interrupt() Tom Tromey
2000-04-01  0:00   ` Thread.interrupt() Tom Tromey
2000-03-14 15:59 ` Thread.interrupt() Jesper Peterson
2000-04-01  0:00   ` Thread.interrupt() Jesper Peterson
2000-04-01  0:00 ` Thread.interrupt() Boehm, Hans
2000-03-14  7:47 Thread.interrupt() Miles Sabin
2000-04-01  0:00 ` Thread.interrupt() Miles Sabin
2000-03-14  6:00 Thread.interrupt() Miles Sabin
2000-03-14  7:36 ` Thread.interrupt() Jeff Sturm
2000-03-14 10:58   ` Thread.interrupt() Tom Tromey
2000-04-01  0:00     ` Thread.interrupt() Tom Tromey
2000-04-01  0:00   ` Thread.interrupt() Jeff Sturm
2000-04-01  0:00 ` Thread.interrupt() Miles Sabin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=140D21516EC2D3119EE700902787664456E6FA@hplex1.hpl.hp.com \
    --to=hans_boehm@hp.com \
    --cc=java-discuss@sourceware.cygnus.com \
    --cc=jep@esec.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).