This would require:
- updateables &c in Launcher being pseudo-ThreadLocal? (we'd need to be be able to search for them by thread)
- for python to take a critical section in its interpreter, so that any code that it executes could touch the rendering thread.
But, we'd have to make sure that any iUpdatebles that got registered get registered in the correct thread (this could be problematic for things like animations). Perhaps begin/endExecutes could be driven from the main renderer, with the main renderer thread being blocked, waiting for the Field thread to complete one update (but not it's repaint).
It's also possible this is needed / would help with interfacing to Processing's direct drive threading model.
