On Apr 19, 7:21 pm, Piet van Oostrum wrote:
> while time.time() - t < 0.5 or not self._modified:
> print >> sys.stderr, "Going to sleep\n"
> self._mod_lock.wait(timeout=1)
> print >> sys.stderr, "Ok time to see if we must
> stephane.bisin...@gmail.com (sb) wrote:
>>> By the way, I wonder why you need a timeout in your wait. I think the
>>> notifications should be sufficient to keep the gui updated.
>sb> The reason is simple: when first downloading the contactss list, I
>sb> receive a swarm of *Updated() calls
On Apr 19, 4:50 pm, a...@pythoncraft.com (Aahz) wrote:
> The redraw thread should keep track of the last time it did a redraw;
> each time it receives an update event, it should check to see whether it
> has been more than a specified period of time since the last redraw.
That's what I do ;)
--
ht
In article <6c04c7da-6b54-4a49-803f-aac3126e3...@f19g2000yqh.googlegroups.com>,
wrote:
>On Apr 18, 8:29=A0pm, Piet van Oostrum wrote:
>>
>> By the way, I wonder why you need a timeout in your wait. I think the
>> notifications should be sufficient to keep the gui updated.
>
>The reason is simpl
On Apr 19, 3:14 pm, stephane.bisin...@gmail.com wrote:
> Ok here's the deal: I'm not ending up in the gtk frontend. My code is
> for the ncurses frontend, so there is no "import gtk" and "gtk.main()"
> that gets executed in that case. But it is definitely around the
> gobject thing, I'll try to sea
On Apr 19, 2:31 pm, Piet van Oostrum wrote:
> It appears that GTK and Python threads are incompatible UNLESS you call
> gtk.gdk.threads_init() before gtk.main(). In your case you can do it
> after the import gtk in contact_list.py. Then it should work.
Ok here's the deal: I'm not ending up in the
On Apr 18, 8:29 pm, Piet van Oostrum wrote:
> 2. Importing in a thread is discouraged. I think it is cleaner to put
> the import sys in the top of the module.
Yes I know I shouldn't import inside of threads, but that is something
that is going away, it's just for debugging this issue.
On Apr
> stephane.bisin...@gmail.com (sb) wrote:
>sb> I'll also file a bug report because I am more and more convinced this
>sb> is a bug, if anything else at least in the documentation...
I looked at it more closely, and I found that the Condition.wait is
stuck on obtaining the GIL while the main t
> stephane.bisin...@gmail.com (SB) wrote:
>SB> On Apr 18, 10:24 am, Piet van Oostrum wrote:
>>>
>>> I haven't run it (too much hassle to setup) but I noticed one strange
>>> thing in your code:
>>>
>>> ,
>>> | def groupUpdated(self, gView):
>>> | # Acquire the lock to do modific
> "Gabriel Genellina" (GG) wrote:
>GG> If another thread has acquired the lock, cond.wait() doesn't return. Add
>GG> these lines at the end of your test and see:
>GG> sleep(2)
>GG> print "Main thread - cond.acquire()"
>GG> cond.acquire()
>GG> sleep(2)
>GG> print "Main thread - cond.release()
In article <19475d1c-ee83-4466-ba55-b352ea760...@x5g2000yqk.googlegroups.com>,
wrote:
>On Apr 18, 4:28=A0pm, a...@pythoncraft.com (Aahz) wrote:
>>
>> Essentially, you use the Queue instead of the Condition. =A0When you want
>> to explicitly give up control in a thread, you get() on the Queue unti
On Apr 18, 4:28 pm, a...@pythoncraft.com (Aahz) wrote:
> Essentially, you use the Queue instead of the Condition. When you want
> to explicitly give up control in a thread, you get() on the Queue until
> you get an object (with the optional timeout). When the other thread is
> done processing, it
In article <8373c927-5ef2-4511-a439-25caa3fd6...@v15g2000yqn.googlegroups.com>,
wrote:
>On Apr 18, 2:05=A0pm, a...@pythoncraft.com (Aahz) wrote:
>>
>> Whether or not there's a bug, you likely will simplify your code if you
>> switch to using a Queue().
>
>I'm sorry, but I can't see how the queue
On Apr 18, 2:05 pm, a...@pythoncraft.com (Aahz) wrote:
> Whether or not there's a bug, you likely will simplify your code if you
> switch to using a Queue().
I'm sorry, but I can't see how the queue would help me on this, since
I only have 2 threads and the documentation esplicitly states that it
In article <1eb44e98-3f32-42b3-92f8-1e635428c...@q9g2000yqc.googlegroups.com>,
wrote:
>
>I have a problem with Condition.wait(), it doesn't return after the
>given timeout. The thing is that if I try to create a simple program,
>it works as expected, but in the actual code, the timeout is not
>re
On Apr 18, 10:24 am, Piet van Oostrum wrote:
>
> I haven't run it (too much hassle to setup) but I noticed one strange
> thing in your code:
>
> ,
> | def groupUpdated(self, gView):
> | # Acquire the lock to do modifications
> | self._mod_lock.acquire()
> |
> | if not
> stephane.bisin...@gmail.com (SB) wrote:
>SB> Hi all,
>SB> I have a problem with Condition.wait(), it doesn't return after the
>SB> given timeout. The thing is that if I try to create a simple program,
>SB> it works as expected, but in the actual code, the timeout is not
>SB> respected (albei
En Fri, 17 Apr 2009 22:20:11 -0300, escribió:
I have a problem with Condition.wait(), it doesn't return after the
given timeout. The thing is that if I try to create a simple program,
it works as expected, but in the actual code, the timeout is not
respected (albeit the notify()s work as expect
Hi all,
I have a problem with Condition.wait(), it doesn't return after the
given timeout. The thing is that if I try to create a simple program,
it works as expected, but in the actual code, the timeout is not
respected (albeit the notify()s work as expected).
You can find the code I am talking ab
19 matches
Mail list logo
