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

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

Making it a MultiThread!

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

Contents

  Making it a MultiThread! stas poritskiy <stascrash@gmail.com> - 2013-09-20 05:56 -0700
    Re: Making it a MultiThread! stas poritskiy <stascrash@gmail.com> - 2013-09-20 09:11 -0700
      Re: Making it a MultiThread! Piet van Oostrum <piet@vanoostrum.org> - 2013-09-21 21:00 -0400
        Re: Making it a MultiThread! Chris Angelico <rosuav@gmail.com> - 2013-09-22 11:18 +1000
        Re: Making it a MultiThread! stas poritskiy <stascrash@gmail.com> - 2013-09-23 07:14 -0700
          Re: Making it a MultiThread! Piet van Oostrum <piet@vanoostrum.org> - 2013-09-24 07:28 -0400

#54468 — Making it a MultiThread!

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 that i 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 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 !

[toc] | [next] | [standalone]

#54486

On Friday, September 20, 2013 7:56:16 AM UTC-5, stas poritskiy wrote:
> 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 that i 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 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 !

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

[toc] | [prev] | [next] | [standalone]

#54568

stas poritskiy <stascrash@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@vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]

[toc] | [prev] | [next] | [standalone]

#54569

On Sun, Sep 22, 2013 at 11:00 AM, Piet van Oostrum <piet@vanoostrum.org> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#54641

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.

On Saturday, September 21, 2013 8:00:29 PM UTC-5, Piet van Oostrum wrote:
> stas poritskiy <stascrash@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@vanoostrum.org>
> 
> WWW: http://pietvanoostrum.com/
> 
> PGP key: [8DAE142BE17999C4]

[toc] | [prev] | [next] | [standalone]

#54689

stas poritskiy <stascrash@gmail.com> writes:

> 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.
-- 
Piet van Oostrum <piet@vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]

[toc] | [prev] | [standalone]

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

csiph-web