Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Windows - select.select, timeout and KeyboardInterrupt

Reply
Thread Tools

Windows - select.select, timeout and KeyboardInterrupt

 
 
Paul Moore
Guest
Posts: n/a
 
      05-06-2010
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 before raising
KeyboardInterrupt.

Is this a known limitation on Windows? I see no mention of it in the
documentation. Assuming it is a known limitation, is there a way round
it? (I'm writing a tiny server using asyncore/asynchat, and the
delayed response to Ctrl-C is a mild nuisance. Solutions such as "use
twisted", while probably the sensible option in a wider context, don't
really apply here - I need something within the confines of the stdlib
if it's to be worth doing).

Thanks,
Paul
 
Reply With Quote
 
 
 
 
Thomas Heller
Guest
Posts: n/a
 
      05-06-2010
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 before raising
> KeyboardInterrupt.
>
> Is this a known limitation on Windows? I see no mention of it in the
> documentation. Assuming it is a known limitation, is there a way round
> it? (I'm writing a tiny server using asyncore/asynchat, and the
> delayed response to Ctrl-C is a mild nuisance. Solutions such as "use
> twisted", while probably the sensible option in a wider context, don't
> really apply here - I need something within the confines of the stdlib
> if it's to be worth doing).


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.

I guess the best way might be to split your select.select() call into several
ones, using a smaller timeout like 1 second for example.

BTW: I have experimented with calling the win32 function SetConsoleCtrlHandler()
before the call to select.select(). This allows to install a python callback
function which is called when Ctrl+C is pressed. However it seems this callback
is not able to interrupt the select() call - but it can 'raise SystemExit()'
which will terminate the script. Here is the code:

"""
import ctypes, select, socket

@ctypes.WINFUNCTYPE(ctypes.c_int, ctypes.c_uint)
def HandlerRoutine(dwCtrlType):
print "hoppla", dwCtrlType
if dwCtrlType == 0: # CTRL+C
raise SystemExit()
return 1

s = socket.socket()

print "Waiting."
ctypes.windll.kernel32.SetConsoleCtrlHandler(Handl erRoutine, 1)
select.select([s], [], [], 30)
ctypes.windll.kernel32.SetConsoleCtrlHandler(Handl erRoutine, 0)
print "Done."
"""

 
Reply With Quote
 
 
 
 
Paul Moore
Guest
Posts: n/a
 
      05-07-2010
On 6 May, 20:58, Thomas Heller <(E-Mail Removed)> 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 be worth me submitting a documentation
patch noting that select.select is not interruptible on Windows?

> I guess the best way might be to split your select.select() call into several
> ones, using a smaller timeout like 1 second for example.


Yes, that's probably good enough for my case.

> BTW: I have experimented with calling the win32 function SetConsoleCtrlHandler()
> before the call to select.select(). *This allows to install a python callback
> function which is called when Ctrl+C is pressed. *However it seems this callback
> is not able to interrupt the select() call - but it can 'raise SystemExit()'
> which will terminate the script. *Here is the code:


That's useful - I doubt I'll need it for this case, but I'll keep it
in mind for the future.

Thanks for the help.
Paul.
 
Reply With Quote
 
Giampaolo RodolÓ
Guest
Posts: n/a
 
      05-07-2010
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.

--- Giampaolo
http://code.google.com/p/pyftpdlib
http://code.google.com/p/psutil


2010/5/6 Paul Moore <(E-Mail Removed)>:
> >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 before raising
> KeyboardInterrupt.
>
> Is this a known limitation on Windows? I see no mention of it in the
> documentation. Assuming it is a known limitation, is there a way round
> it? (I'm writing a tiny server using asyncore/asynchat, and the
> delayed response to Ctrl-C is a mild nuisance. Solutions such as "use
> twisted", while probably the sensible option in a wider context, don't
> really apply here - I need something within the confines of the stdlib
> if it's to be worth doing).
>
> Thanks,
> Paul
> --
> http://mail.python.org/mailman/listinfo/python-list
>

 
Reply With Quote
 
Antoine Pitrou
Guest
Posts: n/a
 
      05-07-2010
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.

Under Unix, it's easy to have a separate fd on which you write a byte
when an signal comes, and which wakes up your select() call. Under
Windows, it may be more involved -- first because select() only takes
sockets, not pipes.

 
Reply With Quote
 
Paul Moore
Guest
Posts: n/a
 
      05-07-2010
On 7 May 2010 15:36, Giampaolo RodolÓ <(E-Mail Removed)> 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
 
Reply With Quote
 
Giampaolo RodolÓ
Guest
Posts: n/a
 
      05-07-2010
2010/5/7 Antoine Pitrou <(E-Mail Removed)>:
> 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
 
Reply With Quote
 
Antoine Pitrou
Guest
Posts: n/a
 
      05-07-2010
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?


 
Reply With Quote
 
exarkun@twistedmatrix.com
Guest
Posts: n/a
 
      05-08-2010
On 7 May, 07:25 pm, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>On 7 May 2010 15:36, Giampaolo RodolÓ <(E-Mail Removed)> 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
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      05-08-2010
In message <(E-Mail Removed)>,
(E-Mail Removed) 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?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: exception KeyboardInterrupt and os.system command jepler@unpythonic.net Python 3 11-28-2005 06:21 PM
exception KeyboardInterrupt and os.system command darren kirby Python 1 11-27-2005 11:18 PM
Socket object and KeyboardInterrupt exception PantherSE Python 0 05-16-2005 09:10 PM
Timeout::timeout and Socket timeout Mark Probert Ruby 1 10-06-2004 09:30 AM
KeyboardInterrupt and threading Ivan Nestlerode Python 8 01-08-2004 11:12 AM



Advertisments