Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #25838 > unrolled thread

Re: A thread import problem

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: A thread import problem Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-23 01:50 -0400

#25838 — Re: A thread import problem

On Sun, Jul 22, 2012 at 7:14 PM, Bruce Sherwood
<bruce.sherwood@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

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web