This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 20249 - Detect deadlocks
Summary: Detect deadlocks
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC All
: P4 blocker (vote)
Assignee: David Strupl
URL: http://core.netbeans.org/proposals/de...
Keywords: THREAD
Depends on: 69227
Blocks:
  Show dependency tree
 
Reported: 2002-02-07 10:38 UTC by David Strupl
Modified: 2009-09-21 16:20 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Strupl 2002-02-07 10:38:06 UTC
A cleaner exit can be implemented when there is a deadlock or neverending loop
with AWT Event handling thread involved.
Comment 1 Jaroslav Tulach 2002-06-13 04:43:03 UTC
This could be (even in better way) implemented for the new datasystem
implementation. We have a control over the queue, so it should be easy
to find out that a task in the queue is running too long without any
significant activity. We also know everyone who is waiting on a finish
of a task and we can interrupt him and thus break the deadlock.
Comment 2 David Strupl 2002-07-22 09:31:00 UTC
Jesse's main argument against proposed solution was that I could kill
the AWT queue even in case some processor intensive computation is
performed outside the NB platform. I realized that this can be solved
by performing the killing from a MIN_PRIORITY thread. It should ensure
that I stop the thread in question only in case that scheduler lets
run a min priority thread (hopefully in real deadlock). There are
still two issues with this: test whether my claim is true and a
problem with livelock (neverending loop) is not solved by this.
Comment 3 Jesse Glick 2002-07-22 10:48:53 UTC
Re. min pri threads: might work, though JVM spec makes very few
promises about how this sort of thing might work. Would require a lot
of platform testing.

Re. livelocks: yes, these are a whole other problem to detect.
Comment 4 David Konecny 2003-04-30 12:58:19 UTC
What is the status of this issue? I has feeling that it died, but I
might be wrong. Closing as WONTFIX. Feel free to reopen.
Comment 5 Marian Mirilovic 2003-07-25 18:32:44 UTC
Without new informations for long time - verifying, closing.
Comment 6 David Strupl 2007-01-04 22:50:32 UTC
.
Comment 7 David Strupl 2007-01-04 22:51:52 UTC
I don't like giving up my cooool (TM) idea ;-)
Comment 8 David Strupl 2008-04-04 19:51:12 UTC
Still valid ENH with low priority ...
Comment 9 David Strupl 2009-09-21 09:40:40 UTC
I think that with the recent Jarda's implementation of the slowness detector this issue is obsolete. Closing as wontfix.
Comment 10 Jesse Glick 2009-09-21 16:20:31 UTC
There might still be value in a more graceful recovery from deadlocks involving EQ, since the slowness detector is
useless in this case. Whether we _can_ recover from deadlocks reliably is another question.