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.
A cleaner exit can be implemented when there is a deadlock or neverending loop with AWT Event handling thread involved.
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.
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.
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.
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.
Without new informations for long time - verifying, closing.
.
I don't like giving up my cooool (TM) idea ;-)
Still valid ENH with low priority ...
I think that with the recent Jarda's implementation of the slowness detector this issue is obsolete. Closing as wontfix.
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.