public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Boehm, Hans" <hans_boehm@hp.com>
To: "'Miles Sabin'" <msabin@cromwellmedia.co.uk>,
	java-discuss@sourceware.cygnus.com
Subject: RE: Thread.interrupt()
Date: Wed, 15 Mar 2000 11:38:00 -0000	[thread overview]
Message-ID: <140D21516EC2D3119EE700902787664456E700@hplex1.hpl.hp.com> (raw)

I agree that you can invent a protocol that will make it possible to
interrupt a thread blocked on I/O by closing a file descriptor (assuming
that closing a file descriptor actually terminates a read).  The crucial
problem with this is that at least every class in the system that performs
blocking I/O has to play by these rules.  In most cases, you  won't have
control over all of them.  And those implemented by others won't play by
your rules.  For example, I'd be surprised if something like
java.net.URLConnection gave access to all file descriptors it might wait on,
e.g. for name lookups.

Thread.interrupt() was intended to provide a general solution to this
problem, effectively by standardizing the protocol (and making it a bit more
general in the process). 

Hans

-----Original Message-----
From: Miles Sabin [ mailto:msabin@cromwellmedia.co.uk ]
Sent: Wednesday, March 15, 2000 5:51 AM
To: java-discuss@sourceware.cygnus.com
Subject: RE: Thread.interrupt()


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

I don't see this as a problem specific to interruptable IO or
even concurrency. Similar issues might arise in, for example, 
(syntactic) error handling/recovery in a recursive descent 
parser, or any number of other scenarios where the stack is
used to encode an objects state.

In fact, it looks like a straightforward software design issue 
to me. Effectively what you're saying is that cancellation is a 
first class aspect of the behaviour associated with thread B. 
That being so it should be exposed at the interface level and
then implemented in whatever the appropriate way is. For a 
simple example: B's Runnable instance might have a register() 
method to allow the 28-frame-down FD to be associated with the 
the state of thread B as a whole; and a cancel() method 
accessible to A which closes it.

Cheers,


Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
msabin@cromwellmedia.com          http://www.cromwellmedia.com/

WARNING: multiple messages have this Message-ID
From: "Boehm, Hans" <hans_boehm@hp.com>
To: "'Miles Sabin'" <msabin@cromwellmedia.co.uk>,
	java-discuss@sourceware.cygnus.com
Subject: RE: Thread.interrupt()
Date: Sat, 01 Apr 2000 00:00:00 -0000	[thread overview]
Message-ID: <140D21516EC2D3119EE700902787664456E700@hplex1.hpl.hp.com> (raw)
Message-ID: <20000401000000.uNZmEOcZmu0FxV2Wfzjcqghf-wNPA_LT-B9DphrnZ1I@z> (raw)

I agree that you can invent a protocol that will make it possible to
interrupt a thread blocked on I/O by closing a file descriptor (assuming
that closing a file descriptor actually terminates a read).  The crucial
problem with this is that at least every class in the system that performs
blocking I/O has to play by these rules.  In most cases, you  won't have
control over all of them.  And those implemented by others won't play by
your rules.  For example, I'd be surprised if something like
java.net.URLConnection gave access to all file descriptors it might wait on,
e.g. for name lookups.

Thread.interrupt() was intended to provide a general solution to this
problem, effectively by standardizing the protocol (and making it a bit more
general in the process). 

Hans

-----Original Message-----
From: Miles Sabin [ mailto:msabin@cromwellmedia.co.uk ]
Sent: Wednesday, March 15, 2000 5:51 AM
To: java-discuss@sourceware.cygnus.com
Subject: RE: Thread.interrupt()


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

I don't see this as a problem specific to interruptable IO or
even concurrency. Similar issues might arise in, for example, 
(syntactic) error handling/recovery in a recursive descent 
parser, or any number of other scenarios where the stack is
used to encode an objects state.

In fact, it looks like a straightforward software design issue 
to me. Effectively what you're saying is that cancellation is a 
first class aspect of the behaviour associated with thread B. 
That being so it should be exposed at the interface level and
then implemented in whatever the appropriate way is. For a 
simple example: B's Runnable instance might have a register() 
method to allow the 28-frame-down FD to be associated with the 
the state of thread B as a whole; and a cancel() method 
accessible to A which closes it.

Cheers,


Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
msabin@cromwellmedia.com          http://www.cromwellmedia.com/

             reply	other threads:[~2000-03-15 11:38 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-15 11:38 Boehm, Hans [this message]
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  5:51 Thread.interrupt() Miles Sabin
2000-04-01  0:00 ` Thread.interrupt() Miles Sabin
2000-03-14 16:30 Thread.interrupt() Boehm, Hans
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
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=140D21516EC2D3119EE700902787664456E700@hplex1.hpl.hp.com \
    --to=hans_boehm@hp.com \
    --cc=java-discuss@sourceware.cygnus.com \
    --cc=msabin@cromwellmedia.co.uk \
    /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).