python response slow when running external DLL

[jfong at ms4.hinet.net]

jf... at ms4.hinet.net at 2015/11/29  UTC+8 10:55:28AM wrote：
> > >     .....
> > >     .....
> > >     #do the rest
> > >     var_status.set('Download...')
> > >     _thread.start_new_thread(td_download, ())  #must use threading
> > > 
> > > def td_download():
> > >     result = mydll.SayHello()
> > >     if result:
> > >         var_status.set("Download Fail at %s" % hex(result))
> > >         showerror('Romter', 'Download Fail')
> > >     else:
> > >         var_status.set('Download OK')
> > >         showinfo('Romter', 'Download OK')
> > 
> > As td_download() runs in the other thread the var_status.set() methods are 
> > problematic.
> 
> No idea what kind of problem it will encounter. Can you explain?

It might be not a good idea to update GUI in a spawned thread, according to Mark Lutz's book "Programming Python", section "Using Threads with tkinter GUIs"

"If you do use threads in tkinter programs, however, you need to remember that only the main thread (the one that built the GUI and started the mainloop) should generally make GUI calls. At the least, multiple threads should not attempt to update the GUI at the same time..." 
 
> > Another complication that inevitably comes with concurrency: what if the 
> > user triggers another download while one download is already running? If you 
> > don't keep track of all downloads the message will already switch to 
> > "Download OK" while one download is still running.
> 
> Hummm...this thought never comes to my mind. After take a quick test I found, you are right, a second "download" was triggered immediately. That's a shock to me. I suppose the same event shouldn't be triggered again, or at least not triggered immediately, before its previous handler was completed. ...I will take a check later on Borland C++ builder to see how it reacts!
> 
> Anyway to prevent this happens? if Python didn't take care it for us.

then don't use thread if you prefer the GUI freeze.