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

I think we are asking two different questions, and I'm probably overly
optimistic.

If the question is:  "Can Thread.interrupt() be implemented in terms of
pthread_cancel,
without relying on undocumented properties the pthread implementation?" then
the answer
is almost certainly no.

But there are lots of things you can't do without relying on extensions to
the pthreads
implementation (e.g. garbage collection, reasonable cost reference counting,
etc.)

So my question was really: "Can I extend the pthreads
implementation/documentation such that
Thread.interrupt() is implementable in terms of pthread_cancel()?"  In that
case,
the answer is likely to be "yes".

It seems to me that this is a reasonable approach for getting the
functionality on Linux.
Java is likely to eventually be either the most important client of
pthreads, or certainly
one of the most important clients.  Adding minor extensions to make them
cooperate seems
more than reasonable.

It does mean that you won't get instantaneous support for this feature on
all platforms.
But at least you have a path to get there on each platform.

I haven't a clue whether, for example, the linux_threads implementation,
would actually
need to be changed.  Certainly more of its behavior would have to be exposed
to gcj.
(I implemented this once in a different context while I was working for SGI.
My recollection
is that in that case essentially no pthread code changes were required in
the end.)

Hans

-----Original Message-----
From: Tom Tromey [ mailto:tromey@cygnus.com ]
Sent: Tuesday, March 14, 2000 10:52 AM
To: Boehm, Hans
Cc: 'Miles Sabin'; java-discuss@sourceware.cygnus.com
Subject: RE: Thread.interrupt()

Hans> It seems to me that Thread.interrupt() should in fact be
Hans> implemented (on Posix platforms) using pthread_cancel, though it
Hans> may take some work on the pthreads side to make that fly.

I don't see how this can be done, because I don't see how you can stop
a cancellation in progress (eg, throwing an exception from a cleanup
handler is undefined behavior).  Bryce and I have been talking about
just implementing condition variables on our own for POSIX, since the
POSIX and Java models don't line up enough.  I'd love to be wrong
about this.

Tom

WARNING: multiple messages have this Message-ID
From: "Boehm, Hans" <hans_boehm@hp.com>
To: "'Tom Tromey'" <tromey@cygnus.com>, "Boehm, Hans" <hans_boehm@hp.com>
Cc: "'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: <140D21516EC2D3119EE700902787664456E6F6@hplex1.hpl.hp.com> (raw)
Message-ID: <20000401000000.Ixo9v1d55OFJn4C_UXify17kdyQKmSNKwzpX0RDryv8@z> (raw)

I think we are asking two different questions, and I'm probably overly
optimistic.

If the question is:  "Can Thread.interrupt() be implemented in terms of
pthread_cancel,
without relying on undocumented properties the pthread implementation?" then
the answer
is almost certainly no.

But there are lots of things you can't do without relying on extensions to
the pthreads
implementation (e.g. garbage collection, reasonable cost reference counting,
etc.)

So my question was really: "Can I extend the pthreads
implementation/documentation such that
Thread.interrupt() is implementable in terms of pthread_cancel()?"  In that
case,
the answer is likely to be "yes".

It seems to me that this is a reasonable approach for getting the
functionality on Linux.
Java is likely to eventually be either the most important client of
pthreads, or certainly
one of the most important clients.  Adding minor extensions to make them
cooperate seems
more than reasonable.

It does mean that you won't get instantaneous support for this feature on
all platforms.
But at least you have a path to get there on each platform.

I haven't a clue whether, for example, the linux_threads implementation,
would actually
need to be changed.  Certainly more of its behavior would have to be exposed
to gcj.
(I implemented this once in a different context while I was working for SGI.
My recollection
is that in that case essentially no pthread code changes were required in
the end.)

Hans

-----Original Message-----
From: Tom Tromey [ mailto:tromey@cygnus.com ]
Sent: Tuesday, March 14, 2000 10:52 AM
To: Boehm, Hans
Cc: 'Miles Sabin'; java-discuss@sourceware.cygnus.com
Subject: RE: Thread.interrupt()

Hans> It seems to me that Thread.interrupt() should in fact be
Hans> implemented (on Posix platforms) using pthread_cancel, though it
Hans> may take some work on the pthreads side to make that fly.

I don't see how this can be done, because I don't see how you can stop
a cancellation in progress (eg, throwing an exception from a cleanup
handler is undefined behavior).  Bryce and I have been talking about
just implementing condition variables on our own for POSIX, since the
POSIX and Java models don't line up enough.  I'd love to be wrong
about this.

Tom

             reply	other threads:[~2000-03-14 11:26 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-14 11:26 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 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 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  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=140D21516EC2D3119EE700902787664456E6F6@hplex1.hpl.hp.com \
    --to=hans_boehm@hp.com \
    --cc=java-discuss@sourceware.cygnus.com \
    --cc=msabin@cromwellmedia.co.uk \
    --cc=tromey@cygnus.com \
    /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).