A thread import problem

[Bruce Sherwood]

Thanks much for this suggestion. I'm not sure I've correctly
understood the operation "start_new_thread(lambda: __import__(<your
module>), ())". By "your module" do you mean the user program which
imported the module that will execute start_new_thread? It hadn't
occurred to me to have A import B and B import A, though now that you
describe this (if that's indeed what you mean) it makes sense. The
original instance of A won't get past its initial import statement
because the main loop won't return to it.

Bruce Sherwood

On Sat, Jul 21, 2012 at 2:32 AM, Dieter Maurer <dieter at handshake.de> wrote:
> Bruce Sherwood <bruce.sherwood at gmail.com> writes:
>> ...
>> from visual import box, rate
>> b = box()
>> while True:
>>     rate(100) # no more than 100 iterations per second
>>     b.pos.x += .01
>>
>> This works because a GUI environment is invoked by the visual module
>> in a secondary thread (written mainly in C++, connected to Python by
>> Boost). The OpenGL rendering of the box in its current position is
>> driven by a 30-millisecond timer. This works fine with any environment
>> other than Mac Cocoa.
>>
>> However, the Mac Cocoa GUI environment and interact loop are required
>> to be the primary thread, so the challenge is to have the visual
>> module set up the Cocoa environment, with the user's program running
>> in a secondary thread. Any ideas?
>
> The usual approach to this situation is to invoke the user code via
> a callback from the UI main loop or invoke it explicitely
> after the UI system has been set up immediately before its main loop
> is called. Might look somehow like this:
>
> main thread:
>
> from thread import start_new_thread
> from visual import setup_gui, start_main_loop
> setup_gui() # sets up the GUI subsystem
> start_new_thread(lambda: __import__(<your module>), ())
> start_main_loop()