4 ms·
Neat idea, but checkout that horrible horrible synchronous message pass to the gtk idle thread ... def execute((R, function, args, kwargs)): R.resu
by audidude 17y ago
Neat idea, but checkout that horrible horrible synchronous message pass to the gtk idle thread ...
def execute((R, function, args, kwargs)):
R.result = apply(function, args, kwargs)
while R.result is NoResult:
time.sleep(0.01)
return R.result
ouch.
- tudorachim 17y agoI was under the impression that time.sleep'ing all over the place was the only way to let threads do their work in python because that's one of the few ways to release the GIL. Is there some other way to get this done (that doesn't involve C modules)?
- epage 17y agogtk.threads_enter() try: blah finally: gtk.threads_leave() or even better and wrap that as a context manager so you do with gtk_lock(): blah
- audidude 17y agoInstead, use a "message reply" concept. For example, for your data you could send a tuple with a callback or a condition. Then block on the condition, and have the lambda/delegate in the idle thread signal the condition. Make sure you hold the lock for the conditions mutex before sending the message though so that it is not a race condition. #Sender callback = SomeFunc mutex.lock() def worker(): # ran in main callback() mutex.lock() cond.signal() mutex.unlock() send_msg_to_idle(0, worker) cond.wait() mutex.unlock()
- audidude 17y agoand if i wasn't clear, the reason this is bad is because you wake up the cpu every 10ms to check. this is quite bad for power consumption, especially if it is a critical path in your framework.