Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #99789
| 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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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