Making it a MultiThread!

[stas poritskiy]

Hello All!

I have a general question,
i was posting here earlier while trying to troubleshoot a few things while developing an application, i was able to hit all of my goals, and make things work! Thank you all who contributed to my research, and again, sorry forpoor formatting of the threads, i am slowly learning

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

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

I was thinking to create a new py-module, and reference all other modules/class to it, and create thread.start() objects, that would execute the GUI part, other will handle GUI Updates, and other - will be doing the processing.

Please share some of your thought on this approach, or maybe you may suggest a more effective way.
thanks !

 

[stas poritskiy]

Hello All!



I have a general question,

i was posting here earlier while trying to troubleshoot a few things while developing an application, i was able to hit all of my goals, and make things work! Thank you all who contributed to my research, and again, sorry for poor formatting of the threads, i am slowly learning



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



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



I was thinking to create a new py-module, and reference all other modules/class to it, and create thread.start() objects, that would execute the GUIpart, other will handle GUI Updates, and other - will be doing the processing.



Please share some of your thought on this approach, or maybe you may suggest a more effective way.

thanks !

Here is some CODE that i wrote to present the working case.
my main program is split in multiple modules, but this structure should represent what i am trying to get.

module name: multiProcessLauncher.py

import multiprocessing
import gui

def main():
jobs = []
p = multiprocessing.Process(target=gui.basicGui)
jobs.append(p)
p.start()

if __name__ == '__main__':
main()
pass


Module Name: gui.py

from Tkinter import *
import tkMessageBox
import Tkinter
import multiProcessLauncher
import action

def basicGui():
g = action.Action()
print "GUI"
processor = multiProcessLauncher
name = processor.multiprocessing.current_process().name
print name, "starting"
print name, "exiting"

top = Tk()
button = Button(top, text = "Press Me", command = g.do_something)
button.pack()
top.mainloop()

def main():
pass
if __name__ == "__main__":
main()

Module Name: action.py

class Action(object):
def __init__(self):
self.text = "Running Action"
def do_something(self):
print self.text

i am trying to figure out how to make use of multiprocessing access the PRINT from the action.py using the GUI button. if you run the code and press the button, the console will read nothing, but as soon as you close the GUI,it spits out the text to console. I read about using Que, but i am not sure how to implement, could someone suggest how? thank you

 

[Piet van Oostrum]

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.

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.

 

[Chris Angelico]

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...

Hmm. When I first learned GUI programming (on OS/2), the advice was
one tenth of a second absolute maximum, or spin off a thread. But yes,
the advice is the same. Keep your main thread REALLY responsive.

ChrisA

 

[stas poritskiy]

Thanks for getting back to me, so i assume it is OK to have a very very long file? The sample code i posted here is basically the barebones of the main app.
so, combining the GUI-file(gui.py) with main code is acceptable? Separating them into modules was initially the attempt to keep things in order.

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.





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 <[email protected]>

WWW: http://pietvanoostrum.com/

PGP key: [8DAE142BE17999C4]

 

[Piet van Oostrum]

Thanks for getting back to me, so i assume it is OK to have a very
very long file? The sample code i posted here is basically the
barebones of the main app.
so, combining the GUI-file(gui.py) with main code is acceptable?
Separating them into modules was initially the attempt to keep things
in order.

Keeping things in separate modules is still OK. Just don't use circular
imports. Keeping the logic of your applcation and the GUI in separate
files is usually a good idea. And make sure the dependencies between the
modules are simple. Very, very long files usually are not a good idea.

Also you imported multiprocessing through anothe module. This obscures
the structure of the application, and is unnecesary. You should only
access a module through another module if you add a layer of abstraction
that makes it easier or more powerful.