Prev: crash in Py_EnterRecursiveCall
Next: List comprehension + lambdas - strange behaviour
From: Giampaolo Rodolà on 8 May 2010 07:47
2010/5/7 Antoine Pitrou <solipsis(a)pitrou.net>:
> 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.

Probably, I'll try to write a benchmark script and see what happens.

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

Assuming loop() function does something like this:

...
select.select(r, w, e, timeout)
scheduler() # checks for scheduled calls to be fired
...

....imagine a case where there's a connection (aka a dispatcher
instance) which does not receive or send any data *and* a scheduled
call which is supposed to be fired after, say, 5 seconds.
The entire loop would hang on select.select() which won't return for
30 seconds because the socket is not ready for reading and/or writing
resulting in scheduler() be called too late.


--- Giampaolo
http://code.google.com/p/pyftpdlib
http://code.google.com/p/psutil
From: Antoine Pitrou on 8 May 2010 10:00
On Sat, 8 May 2010 13:47:53 +0200
Giampaolo Rodolà <g.rodola(a)gmail.com> wrote:
>
> Assuming loop() function does something like this:
>
> ...
> select.select(r, w, e, timeout)
> scheduler() # checks for scheduled calls to be fired
> ...
>
> ...imagine a case where there's a connection (aka a dispatcher
> instance) which does not receive or send any data *and* a scheduled
> call which is supposed to be fired after, say, 5 seconds.
> The entire loop would hang on select.select() which won't return for
> 30 seconds because the socket is not ready for reading and/or writing
> resulting in scheduler() be called too late.

Well, obviously you have to change the timeout based on the delay for
the next scheduled call. If your patch doesn't do that, it probably
needs fixing :)

Regards

Antoine.
From: exarkun on 8 May 2010 09:57
On 07:48 am, ldo(a)geek-central.gen.new_zealand wrote:
>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?

With WaitForMultipleObjects on Windows, epoll on Linux, kqueue on BSD,
event completion on Solaris, etc...

Sound like more work than using select() everywhere? Yea, a bit. But
not once you abstract it away from your actual application code. After
all, it's not like these *do* different things. They all do the same
thing (basically) - differently.

Jean-Paul
From: exarkun on 8 May 2010 10:00
On 11:47 am, g.rodola(a)gmail.com wrote:
>2010/5/7 Antoine Pitrou <solipsis(a)pitrou.net>:
>>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.
>
>Probably, I'll try to write a benchmark script and see what happens.
>>>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?
>
>Assuming loop() function does something like this:
>
> ...
> select.select(r, w, e, timeout)
> scheduler() # checks for scheduled calls to be fired
> ...
>
>...imagine a case where there's a connection (aka a dispatcher
>instance) which does not receive or send any data *and* a scheduled
>call which is supposed to be fired after, say, 5 seconds.
>The entire loop would hang on select.select() which won't return for
>30 seconds because the socket is not ready for reading and/or writing
>resulting in scheduler() be called too late.

This would be an intensely lame way to implement support for scheduled
callbacks. Try this trivial modification instead, to make it awesome:

...
select.select(r, w, e, scheduler.time_until_next_call())
scheduler.run()
...

(Or maybe just use Twisted. ;)

Jean-Paul
From: Giampaolo Rodolà on 8 May 2010 11:03
2010/5/8 Antoine Pitrou <solipsis(a)pitrou.net>:
> On Sat, 8 May 2010 13:47:53 +0200
> Giampaolo Rodolà <g.rodola(a)gmail.com> wrote:
>>
>> Assuming loop() function does something like this:
>>
>>      ...
>>      select.select(r, w, e, timeout)
>>      scheduler()  # checks for scheduled calls to be fired
>>      ...
>>
>> ...imagine a case where there's a connection (aka a dispatcher
>> instance) which does not receive or send any data *and* a scheduled
>> call which is supposed to be fired after, say, 5 seconds.
>> The entire loop would hang on select.select() which won't return for
>> 30 seconds because the socket is not ready for reading and/or writing
>> resulting in scheduler() be called too late.
>
> Well, obviously you have to change the timeout based on the delay for
> the next scheduled call. If your patch doesn't do that, it probably
> needs fixing :)
>
> Regards
>
> Antoine.

No it doesn't and I didn't consider this solution at the time.
Thanks. =)


--- Giampaolo
http://code.google.com/p/pyftpdlib
http://code.google.com/p/psutil
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: crash in Py_EnterRecursiveCall
Next: List comprehension + lambdas - strange behaviour