Making it a MultiThread!

Piet van Oostrum piet at vanoostrum.org
Sat Sep 21 21:00:29 EDT 2013


stas poritskiy <stascrash at gmail.com> writes:

>> I am working on integration of multiple GUI (Tkinter) elements, such
>> a progress bar, label update, etc, and throughout my research i
>> discovered that i need to have Threading modules used to distribute
>> the calls for GUI update and processing of my main App.

In general your GUI should be in your main process/thread. For example
your program doesn't run on Mac OS X because you cannot run the GUI in
another process or thread.

Now if your GUI actions are starting some actions that last more than a
few tenths of a second, you should run these actions in another thread
or process (usually a thread will work), otherwise the GUI becomes
unresponsive. If you want to exchange some information between the GUI
and that thread/process you can use a Queue object, or just give the
information from the GUI at the start of the thread.

>> My Application is broken into multiple Classes(modules), and i wanted
>> to hear your thought on the best practices to implement the Threading
>> model.

The structure of you modules isn't good. There are circular imports, and
that is a sign the the design needs to be simplified:

multiProcessLauncher imports gui.
gui imports multiProcessLauncher.

The latter import isn't necessary. 

Instead of

import multiProcessLauncher
processor = multiProcessLauncher
name = processor.multiprocessing.current_process().name

you can just use:

import multiprocessing
name = multiprocessing.current_process().name

My advice would be to just do the GUI in the main module, and if the
Action needs more time, the create a new Thread or Process in the Action
class.

-- 
Piet van Oostrum <piet at vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]



More information about the Python-list mailing list