Am 09.05.2010 11:59, schrieb Lawrence D'Oliveiro:
In message,
exar...@twistedmatrix.com wrote:
On 07:48 am, l...@geek-central.gen.new_zealand wrote:
In message,
exar...@twistedmatrix.com wrote:
This is a good example of why it's a bad idea to use select on
Windows.
Instead, use WaitForMulti
In message ,
exar...@twistedmatrix.com wrote:
> On 07:48 am, l...@geek-central.gen.new_zealand wrote:
>
>>In message ,
>>exar...@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 suppo
2010/5/8 Antoine Pitrou :
> On Sat, 8 May 2010 13:47:53 +0200
> Giampaolo Rodolà 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
On 11:47 am, g.rod...@gmail.com wrote:
2010/5/7 Antoine Pitrou :
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 performan
On 07:48 am, l...@geek-central.gen.new_zealand wrote:
In message ,
exar...@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
On Sat, 8 May 2010 13:47:53 +0200
Giampaolo Rodolà 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 di
2010/5/7 Antoine Pitrou :
> 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.
P
In message ,
exar...@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?
--
http://mail.python.org/mailman/listinfo/python-list
On 7 May, 07:25 pm, p.f.mo...@gmail.com wrote:
On 7 May 2010 15:36, Giampaolo Rodol� 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
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
2010/5/7 Antoine Pitrou :
> 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 suc
On 7 May 2010 15:36, Giampaolo Rodolà 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
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 s
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).
I think this should be signaled on the bug tracker.
--- Giampao
On 6 May, 20:58, Thomas Heller wrote:
> If you look at the source code for time.sleep(), which CAN be interrupted
> by pressing Ctrl-C, you will find that it is carefully programmed to be
> interruptible (sp?). Which is not the case for select.select(), obviously.
Thanks - given this, would it b
Paul Moore schrieb:
>>From a quick experiment, it seems that select.select with a timeout
> doesn't react to a keyboard interrupt until the timeout expires.
> Specifically, if I do
>
> s = socket.socket()
> select.select([s], [], [], 30)
>
> and then press Ctrl-C, Python waits for the 30 seconds
16 matches
Mail list logo
