A thread import problem

[Bruce Sherwood]

Thanks much for the useful suggestion, and also thanks for your
sympathy and understanding of my plight!

Bruce Sherwood

On Sun, Jul 22, 2012 at 11:50 PM, Devin Jeanpierre
<jeanpierreda at gmail.com> wrote:
> On Sun, Jul 22, 2012 at 7:14 PM, Bruce Sherwood
> <bruce.sherwood at gmail.com> wrote:
>> (2) My hand is forced by Apple no longer supporting Carbon. Among
>> other aspects of this, Carbon can't be used with 64-bit Python, and
>> more and more Mac users of VPython want to use 64-bit Python. So there
>> has to be a version of VPython that is based on Cocoa, but Cocoa is
>> required to be the primary thread. This requirement, combined with the
>> absolute requirement that the VPython API cannot be changed, is the
>> problem I face. I have to turn the architecture inside out,
>> independent of whether the solution meets all criteria for good Python
>> programming style.
>
> I had exactly this problem with Tkinter on Mac. The API involved
> "synchronous" calls to update a GUI written in tkinter, which ran in
> another thread (so e.g. students could call the API from the
> interactive interpreter). This didn't work on new Mac OS X releases,
> because Tkinter had to be run in the main thread after some update --
> and also because of this deadlock issue with imports (but I didn't
> know that until later).
>
> I ended up solving it by running the Tkinter in the main thread of a
> different process, which could handle RPC invocations asynchronously,
> and sending remote invocations via a synchronous RPC library in the
> parent process.
>
> Maybe you can do something similar in your case?
>
> -- Devin