Re: A thread import problem
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.
On Sat, Jul 21, 2012 at 2:32 AM, Dieter Maurer <email@example.com> wrote:
> Bruce Sherwood <firstname.lastname@example.org> 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>), ())
|All times are GMT. The time now is 02:57 AM.|
Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.