Hacker News Reader

Comment by audidude | Hacker News Reader

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.

View on HN

I 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)?

gtk.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

Instead, 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()

and 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.

Reply on news.ycombinator.com