diff options
author | Sven Gothel <[email protected]> | 2012-07-22 04:16:55 +0200 |
---|---|---|
committer | Sven Gothel <[email protected]> | 2012-07-22 04:16:55 +0200 |
commit | 4b5a0f6557d7152ec770bc13ad3c494449de0529 (patch) | |
tree | 12fc93f9e7f34b61c1d5748f0e6a1cd85fc6125b /make/config/jogl/gl-impl-CustomJavaCode-gles2.java | |
parent | adc9522ccaff74eb779d4d33905d76d52acb36bb (diff) |
Fix Bug 606 - New AWT threading implementation breaks .. ; Fix GLAutoDrawable multi-threading w/ proper pattern (hope so)
Considering code changes and remarks:
3ed491213f8f7f05d7b9866b50d764370d8ff5f6
1a91ec5c8b6fd9d9db7bc115569c369fe7b38e9b
3334a924309a9361a448d69bc707d4cce416b430
4f27bcecf7484dc041551f52a5c49e2884cb3867
It seems necessary to have
- recursive locking employed for all semantic actions which changes drawable & context (and the Window resource)
- to avoid deadlock, we have to ensure the locked code segment will not spawn
off to another thread, or a thread holds the lock, spawns of an action requiring the lock. .. sure
- other read-only methods (flags, ..) shall at least utilize a safe local copy of a volatile field
if further use to produce the result is necessary.
- flags like sendReshape require to be volatile to guarantee it's being processed
Patch impacts: AWT/SWT GLCanvas, GLAutoDrawableBase [and it's specializations]
and hopefully closes any loopholes of missing a cache hit, etc.
If you review this and find optimizations, i.e. removing a lock due to semantics etc,
don't hold back and discuss it, please.
Diffstat (limited to 'make/config/jogl/gl-impl-CustomJavaCode-gles2.java')
0 files changed, 0 insertions, 0 deletions