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 <jeanpierr...@gmail.com> wrote: > On Sun, Jul 22, 2012 at 7:14 PM, Bruce Sherwood > <bruce.sherw...@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 -- http://mail.python.org/mailman/listinfo/python-list
