diff options
author | Sven Gothel <[email protected]> | 2014-06-12 21:08:21 +0200 |
---|---|---|
committer | Sven Gothel <[email protected]> | 2014-06-12 21:08:21 +0200 |
commit | 1c5b41f01c9f31f7bd787c6b194f7939904e239b (patch) | |
tree | 55f2e21b59ae3bba390a40bb88e36076272380f6 /make/stub_includes/x11/window-lib.c | |
parent | 5626740d14554acf7a17a73ec12b0893445832d0 (diff) |
Fix NEWT EDTUtil Deadlock on EDTUtil.start()
DisplayImpl.runOnEDTIfAvail(..) issues EDTUtil.start()
while holding it's object-lock - if the EDT is not running,
then invokes the given task.
EDTUtil.start() impl. holds it's own edt-lock
while starting, then releases it's edt-lock while issuing a null-task.
If another thread injects a blocking task right in-between
which also acquires the display's object-lock it deadlocks.
Simply remove issuing the null-task, so EDTUtil.start()
can return immediatly (releasing edt-lock)
and allowing DisplayImpl.runOnEDTIfAvail(..)
also to release it's object-lock.
The other threads task then can be executed,
where the 'starting task' would come second - which is OK,
even though a rare occasion.
Above situation was triggered via AWT/NEWT reparenting w/ forced recreation
via TestParenting01dAWT.
+++
The null-task at EDTUtil.start() was remaining code to ensure
that the EDT completed starting, which is redundant.
Diffstat (limited to 'make/stub_includes/x11/window-lib.c')
0 files changed, 0 insertions, 0 deletions