python response slow when running external DLL

[Peter Otten]

jfong at ms4.hinet.net wrote:

> Peter Otten at 2015/11/27 UTC+8 8:20:54PM wrote：
> 
>> Quick-fix example:
>> def download():
>>     var.set("Starting download...")
>>     root.update_idletasks()
>>     time.sleep(3)
>>     var.set("... done")
> 
> Thanks, Peter, The update_idletasks() works. In my trivial program it's
> easy to apply for there are only two places call the DLL function.
> 
>> A cleaner solution can indeed involve threads; you might adapt the
>> approach from <http://effbot.org/zone/tkinter-threads.htm> (Python 2
>> code).
> 
> Using thread is obviously more logical. I think my mistake was the "while
> busy:  pass" loop which makes no sense because it blocks the main thread,
> just as the time.sleep() does. That's why in your link (and Laura's too)
> the widget.after() scheduling was used for this purpose.

No, the point of both recipes is that tkinter operations are only ever 
invoked from the main thread. The main thread has polling code that 
repeatedly looks if there are results from the helper thread. As far I 
understand the polling method has the structure

f():
   # did we get something back from the other thread?
   # a queue is used to avoid race conditions

   # if yes react.
   # var_status.set() goes here

   # reschedule f to run again in a few millisecs; 
   # that's what after() does
 
> From what I had learned here, the other way I can do is making the codes
> modified as follows. It will get ride of the "result" and "busy" global
> variables, but it also makes the codes looks a little ugly. I think I will
> take the update_idletasks() way in this porting for it seems more simpler,
> and can be used on thread or non-thread calling. Thank you again.
>     .....
>     .....
>     #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.

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.