diff options
author | Sven Gothel <[email protected]> | 2012-06-28 21:22:30 +0200 |
---|---|---|
committer | Sven Gothel <[email protected]> | 2012-06-28 21:22:30 +0200 |
commit | 1a91ec5c8b6fd9d9db7bc115569c369fe7b38e9b (patch) | |
tree | 9882fbf1d2cacaf04471d2ee538c97d4b238993d /make/config/jogl/gl-gl4bc.cfg | |
parent | 53ff91470b73f2f12f0d1cf5cf800a13e46e026e (diff) |
SWT GLCanvas: Fix destroy(), Remove local concurrency hack & out-of-process locking ; Revise threading code; Proper name for SWT unit tests.
SWT GLCanvas:
- Fix destroy()
drawable.setRealized(false); is being called within dispose() method
- Remove local concurrency hack
[MT-0] The hack: 'final GLContext ctx = getContext(); a = null != ctx ? ctx.something() : 0;'
is thread safe locally, however, w/o covering the hole use case of the caller
it makes no sense to add thread safe code here - would be only an illusion.
In case any of the methods are called outside of a locked state
extra care should be added. Maybe we shall expose locking facilities to the user.
However, since the user shall stick to the GLEventListener model while utilizing
GLAutoDrawable implementations, she is safe due to the implicit locked state.
- Removing out-of-process locking
[MT-1] Claiming the recursive lock in the dispose/display/.. methods
and _then_ issuing a complex off-thread GL task could lead to deadlock.
The GL task could involve calling GLEventListener methods, which itself
could try to manipulate the GLCanvas -> deadlock.
Similar to [MT-0] we may need to either find a proper locking mechanism
or simply ignore it and reduce functionality.
TBH .. the number of scenarious of the mentioned deadlock are very limited
and exotic.
- Revise threading code
[MT-2] Besides the other MT-* remarks, the logic whether to spawn off
the GL task and determination which thread to use is too complex and redundant.
(See isRenderThread(), runInGLThread() and runInDesignatedGLThread())
- Proper name for SWT unit tests.
Reflect the semantics.
Diffstat (limited to 'make/config/jogl/gl-gl4bc.cfg')
0 files changed, 0 insertions, 0 deletions