aboutsummaryrefslogtreecommitdiffstats
path: root/src/newt/native/bcm_vc_iv.c
diff options
context:
space:
mode:
authorSven Gothel <[email protected]>2014-06-12 21:08:21 +0200
committerSven Gothel <[email protected]>2014-06-12 21:08:21 +0200
commit1c5b41f01c9f31f7bd787c6b194f7939904e239b (patch)
tree55f2e21b59ae3bba390a40bb88e36076272380f6 /src/newt/native/bcm_vc_iv.c
parent5626740d14554acf7a17a73ec12b0893445832d0 (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 'src/newt/native/bcm_vc_iv.c')
0 files changed, 0 insertions, 0 deletions