Prev: crash in Py_EnterRecursiveCall
Next: List comprehension + lambdas - strange behaviour
From: Paul Moore on 7 May 2010 15:25
On 7 May 2010 15:36, Giampaolo Rodolà <g.rodola(a)gmail.com> wrote:
> You can easily avoid this by setting a lower timeout when calling
> asyncore.loop(), like 1 second or less (for example, Twisted uses
> 0.001 secs).

Thanks, that's what I was considering.

> Actually there's no reason for asyncore to have such a high default
> timeout (30 seconds).

I assumed it was to avoid busy waiting.

> I think this should be signaled on the bug tracker.

If a longer timeout doesn't have issues with busy waiting, then I'd agree.
Paul
From: Giampaolo Rodolà on 7 May 2010 15:55
2010/5/7 Antoine Pitrou <solipsis(a)pitrou.net>:
> Le Fri, 07 May 2010 16:36:44 +0200, Giampaolo Rodolà a écrit :
>> You can easily avoid this by setting a lower timeout when calling
>> asyncore.loop(), like 1 second or less (for example, Twisted uses 0.001
>> secs).
>> Actually there's no reason for asyncore to have such a high default
>> timeout (30 seconds).
>
> The reason for a high default timeout would be to avoid waking the CPU
> and do useless work too often. This is important on laptops and smaller
> devices, in order to conserve power.
>

Of course, but 30 seconds look a little bit too much to me, also
because (I might be wrong here) I noticed that a smaller timeout seems
to result in better performances.
Plus, if scheduled callbacks are ever gonna be added to asyncore we
would be forced to lower the default timeout anyway in order to have a
decent reactivity.


--- Giampaolo
http://code.google.com/p/pyftpdlib
http://code.google.com/p/psutil
From: Antoine Pitrou on 7 May 2010 16:45
Le Fri, 07 May 2010 21:55:15 +0200, Giampaolo Rodolà a écrit :
> Of course, but 30 seconds look a little bit too much to me, also because
> (I might be wrong here) I noticed that a smaller timeout seems to result
> in better performances.

That's probably bogus.

> Plus, if scheduled callbacks are ever gonna be added to asyncore we
> would be forced to lower the default timeout anyway in order to have a
> decent reactivity.

Why?


From: exarkun on 7 May 2010 23:18
On 7 May, 07:25 pm, p.f.moore(a)gmail.com wrote:
>On 7 May 2010 15:36, Giampaolo Rodolà <g.rodola(a)gmail.com> wrote:
>>You can easily avoid this by setting a lower timeout when calling
>>asyncore.loop(), like 1 second or less (for example, Twisted uses
>>0.001 secs).
>
>Thanks, that's what I was considering.

This is a good example of why it's a bad idea to use select on Windows.
Instead, use WaitForMultipleObjects.
>>Actually there's no reason for asyncore to have such a high default
>>timeout (30 seconds).
>
>I assumed it was to avoid busy waiting.
>>I think this should be signaled on the bug tracker.
>
>If a longer timeout doesn't have issues with busy waiting, then I'd
>agree.

The *default* timeout is only the default. An application that knows
better can supply a different value. I'm not sure how much good can be
done by fiddling with the default.

Jean-Paul
From: Lawrence D'Oliveiro on 8 May 2010 03:48
In message <mailman.2760.1273288730.23598.python-list(a)python.org>,
exarkun(a)twistedmatrix.com wrote:

> This is a good example of why it's a bad idea to use select on Windows.
> Instead, use WaitForMultipleObjects.

How are you supposed to write portable code, then?
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: crash in Py_EnterRecursiveCall
Next: List comprehension + lambdas - strange behaviour