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


Groups > comp.lang.python > #99789

Re: python response slow when running external DLL

Path csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From Peter Otten <__peter__@web.de>
Newsgroups comp.lang.python
Subject Re: python response slow when running external DLL
Date Tue, 01 Dec 2015 12:01:14 +0100
Organization None
Lines 97
Message-ID <mailman.66.1448967701.14615.python-list@python.org> (permalink)
References <dc290806-c537-4546-b802-88dff14d81c0@googlegroups.com> <mailman.169.1448615930.20593.python-list@python.org> <f4cf8b4f-94e7-4d97-b144-65f59c20fbc1@googlegroups.com> <mailman.173.1448626828.20593.python-list@python.org> <d6c59a36-38ba-4f26-b949-18f2b226e7e3@googlegroups.com> <mailman.184.1448705627.20593.python-list@python.org> <3ec6a016-dae5-4986-b035-c1a8cd4dc3e7@googlegroups.com>
Mime-Version 1.0
Content-Type text/plain; charset="UTF-8"
Content-Transfer-Encoding 8Bit
X-Trace news.uni-berlin.de oYz2oqRGEkqBmUXcvT9iHQq62E0LeTV3teQP68GQto3g==
Return-Path <python-python-list@m.gmane.org>
X-Original-To python-list@python.org
Delivered-To python-list@mail.python.org
X-Spam-Status OK 0.000
X-Spam-Evidence '*H*': 1.00; '*S*': 0.00; 'else:': 0.03; 'broken': 0.03; 'handler': 0.04; 'modify': 0.04; 'amount:': 0.07; 'blocked': 0.09; 'handlers': 0.09; 'modifies': 0.09; 'of)': 0.09; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'switches': 0.09; 'thread': 0.10; 'python': 0.10; 'anyway': 0.11; 'def': 0.13; 'subject:python': 0.14; 'left,': 0.16; 'poll': 0.16; 'received:80.91.229.3': 0.16; 'received:dip0.t-ipconnect.de': 0.16; 'received:io': 0.16; 'received:plane.gmane.org': 0.16; 'received:psf.io': 0.16; 'received:t-ipconnect.de': 0.16; 'recipes': 0.16; 'result:': 0.16; 'subject:slow': 0.16; 'subject:when': 0.16; 't.join()': 0.16; 't.start()': 0.16; 'thread.': 0.16; 'thread?': 0.16; 'threading': 0.16; 'threads': 0.16; 'threads:': 0.16; 'withdrawal': 0.16; 'wrote:': 0.16; 'later': 0.16; 'found,': 0.18; 'helper': 0.18; "shouldn't": 0.18; 'runs': 0.18; 'prevent': 0.20; '%s"': 0.22; 'builder': 0.22; 'disable': 0.22; 'mind.': 0.22; 'problem:': 0.22; 'suppose': 0.22; 'tkinter': 0.22; '(or': 0.23; 'seems': 0.23; 'second': 0.24; 'import': 0.24; 'thus': 0.24; 'script': 0.25; 'header:User- Agent:1': 0.26; 'example': 0.26; 'header:X-Complaints-To:1': 0.26; 'rest': 0.26; 'separate': 0.27; 'switch': 0.27; 'least': 0.27; 'data,': 0.27; 'idea': 0.28; 'looks': 0.29; 'finds': 0.29; 'measure': 0.29; 'queue': 0.29; 'running.': 0.29; 'random': 0.29; 'code': 0.30; 'operations': 0.31; 'another': 0.32; 'run': 0.33; 'point': 0.33; 'problem': 0.33; 'skip:_ 30': 0.33; 'structure': 0.34; 'previous': 0.34; 'could': 0.35; 'c++': 0.35; 'downloads': 0.35; 'execution': 0.35; 'fail': 0.35; 'something': 0.35; 'sometimes': 0.35; 'but': 0.36; 'there': 0.36; "wasn't": 0.36; 'to:addr:python-list': 0.36; 'subject:: ': 0.37; 'method': 0.37; 'received:org': 0.37; 'thought': 0.37; 'no,': 0.38; 'skip:v 20': 0.38; 'button': 0.38; 'skip:p 20': 0.38; 'end': 0.39; 'goes': 0.39; 'test': 0.39; 'data': 0.39; 'does': 0.39; "didn't": 0.39; 'enough': 0.39; 'easily': 0.39; 'to:addr:python.org': 0.40; 'still': 0.40; 'received:de': 0.40; 'some': 0.40; 'ever': 0.60; 'care': 0.60; 'avoid': 0.61; 'us.': 0.62; 'back': 0.62; 'yes': 0.62; 'times': 0.63; 'here': 0.66; 'account': 0.66; 'results': 0.66; 'money': 0.71; 'race': 0.72; 'state.': 0.72; '.....': 0.76; '"download': 0.84; 'balance.': 0.84; 'complication': 0.84; 'demonstrates': 0.84; 'otten': 0.84; 'shock': 0.84; 'subject:response': 0.91
X-Injected-Via-Gmane http://gmane.org/
X-Gmane-NNTP-Posting-Host p57bd9ec4.dip0.t-ipconnect.de
User-Agent KNode/4.13.3
X-BeenThere python-list@python.org
X-Mailman-Version 2.1.20+
Precedence list
List-Id General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-list/>
List-Post <mailto:python-list@python.org>
List-Help <mailto:python-list-request@python.org?subject=help>
List-Subscribe <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Xref csiph.com comp.lang.python:99789

Show key headers only | View raw


jfong@ms4.hinet.net wrote:

> Peter Otten at 2015/11/28 UTC+8 6:14:09PM wrote:
>> 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
> 
> Have no idea how the main thread poll on all those events (or it use a
> queue)? All I know now is that the main thread(mainloop()?) can be easily
> blocked by event handlers if the handler didn't run as a separate thread.
> 
>> >     .....
>> >     .....
>> >     #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?

While the var_status.set() invoked from the second thread modifies some 
internal data the main thread could kick in and modify (parts of) that same 
data, thus bringing tkinter into an broken state. A simple example that 
demonstrates the problem:

import random
import threading
import time

account = 70

def withdraw(delay, amount):
    global account
    if account >= amount:
        print("withdrawing", amount)
        account -= amount
    else:
        print("failed to withdraw", amount)

threads = []
for i in range(10):
    t = threading.Thread(
        target=withdraw,
        kwargs=dict(delay=.1,
                    amount=random.randrange(1, 20)))
    threads.append(t)
    t.start()

for t in threads:
    t.join()

Before every withdrawal there seems to be a check that ensures that there is 
enough money left, but when you run the script a few times you will still 
sometimes end with a negative balance. That happens when thread A finds 
enough money, then execution switches to thread B which also finds enough 
money, then both threads perform a withdrawal -- oops there wasn't enough 
money for both.
 
>> 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.

A simple measure would be to disable the button until the download has 
ended.

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

python response slow when running external DLL jfong@ms4.hinet.net - 2015-11-26 23:51 -0800
  Re: python response slow when running external DLL Peter Otten <__peter__@web.de> - 2015-11-27 10:18 +0100
    Re: python response slow when running external DLL jfong@ms4.hinet.net - 2015-11-27 03:14 -0800
      Re: python response slow when running external DLL Peter Otten <__peter__@web.de> - 2015-11-27 13:20 +0100
        Re: python response slow when running external DLL jfong@ms4.hinet.net - 2015-11-27 23:37 -0800
          Re: python response slow when running external DLL Peter Otten <__peter__@web.de> - 2015-11-28 11:13 +0100
            Re: python response slow when running external DLL jfong@ms4.hinet.net - 2015-11-28 18:55 -0800
              Re: python response slow when running external DLL jfong@ms4.hinet.net - 2015-11-30 17:03 -0800
              Re: python response slow when running external DLL Peter Otten <__peter__@web.de> - 2015-12-01 12:01 +0100
                Re: python response slow when running external DLL jfong@ms4.hinet.net - 2015-12-01 19:58 -0800
          Re: python response slow when running external DLL Laura Creighton <lac@openend.se> - 2015-11-28 11:51 +0100
            Re: python response slow when running external DLL jfong@ms4.hinet.net - 2015-11-28 19:04 -0800
      Re: python response slow when running external DLL Laura Creighton <lac@openend.se> - 2015-11-27 13:49 +0100

csiph-web