Re: [Python-Dev] Testing Socket Timeouts patch 1519025
Tony Nelson schrieb: Hmm, OK, darn, thanks. MSWindows does allow users to press Ctl-C to send a KeyboardInterrupt, so it's just too bad if I can't find a way to test it from a script. You can use GenerateConsoleCtrlEvent to send Ctrl-C to all processes that share the console of the calling process. BTW, I picked SIGALRM because I could do it all with one thread. Reading POSIX, ISTM that if I sent the signal from another thread, it would bounce off that thread to the main thread during the call to kill(), at which point I got the willies. OTOH, if kill() is more widely available than alarm(), I'll give it a try, but going by the docs, I'd say it isn't. Indeed, alarm should be available on any POSIX system. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
Jean-Paul Calderone [EMAIL PROTECTED] wrote: On Sat, 29 Jul 2006 14:38:38 -0700, Josiah Carlson [EMAIL PROTECTED] wrote: If someone is looking for a project for 2.6 that digs into all sorts of platform-specific nastiness, they could add actual signal sending to the signal module (at least for unix systems). Maybe I am missing something obvious, but what is necessary beyond os.kill()? I note that os.kill() does everything necessary for posix systems. I didn't notice that it took an argument for the kind of signal. A new project for someone: combine all of the methods available to Windows into a single function. What /would/ be useful is a complete sigaction wrapper, but that's a completely separate topic. Like atexit, only a stack per signal? - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
At 9:42 AM +0200 7/30/06, Martin v. Löwis wrote: Tony Nelson schrieb: Hmm, OK, darn, thanks. MSWindows does allow users to press Ctl-C to send a KeyboardInterrupt, so it's just too bad if I can't find a way to test it from a script. You can use GenerateConsoleCtrlEvent to send Ctrl-C to all processes that share the console of the calling process. That looks like it would work, but it seems prone to overkill. To avoid killing all the processes running from a console, the test would need to be run in a subprocess in a new process group. If the test simply sends the event to its own process, all the other processes in its process group would receive the event as well, and probably die. I would expect that all the processes sharing the console would die, but even if they didn't when I tried it, I couldn't be sure that it wouldn't happen elsewhere, say when run from a .bat file. Martin, your advice is usually spot-on, but I don't always understand it. Maybe using it here is just complicated. I expect that GenerateConsoleCtrlEvent() can be called through the ctypes module, though that would make backporting the test to 2.4 a bit more difficult. It looks like the subprocess module can be passed the needed creation flag to make a new process group. The subprocess can send the event to itself, and could return the test result in its result code, so that part isn't so bad. To avoid adding a new file to the distribution, test_socket.test_main() could be modified to look for a command line argument requesting the particular test action. BTW, I picked SIGALRM because I could do it all with one thread. Reading POSIX, ISTM that if I sent the signal from another thread, it would bounce off that thread to the main thread during the call to kill(), at which point I got the willies. OTOH, if kill() is more widely available than alarm(), I'll give it a try, but going by the docs, I'd say it isn't. Indeed, alarm should be available on any POSIX system. Well, if alarm() is available, then the test will work. If not, it will be silently skipped, as are some other tests already in test_socket.py. I can't offhand tell if MSWindows supports alarm(), but RiscOS and OS2 do not. TonyN.:' mailto:[EMAIL PROTECTED] ' http://www.georgeanelson.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
On Sun, 30 Jul 2006 09:50:36 -0700, Josiah Carlson [EMAIL PROTECTED] wrote: Jean-Paul Calderone [EMAIL PROTECTED] wrote: On Sat, 29 Jul 2006 14:38:38 -0700, Josiah Carlson [EMAIL PROTECTED] wrote: If someone is looking for a project for 2.6 that digs into all sorts of platform-specific nastiness, they could add actual signal sending to the signal module (at least for unix systems). Maybe I am missing something obvious, but what is necessary beyond os.kill()? I note that os.kill() does everything necessary for posix systems. I didn't notice that it took an argument for the kind of signal. A new project for someone: combine all of the methods available to Windows into a single function. What /would/ be useful is a complete sigaction wrapper, but that's a completely separate topic. Like atexit, only a stack per signal? I just mean a complete wrapping of sigaction(2). In particular, I need this functionality to properly install a SIGCHLD handler which does not interfer with various I/O functions by installing the handler with the SA_RESTART flag, which is not currently possible using the signal.signal function. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
Tony Nelson schrieb: You can use GenerateConsoleCtrlEvent to send Ctrl-C to all processes that share the console of the calling process. [...] Martin, your advice is usually spot-on, but I don't always understand it. Maybe using it here is just complicated. This was really just in response to your remark that you couldn't find a way to send Ctrl-C programmatically. I researched (in the C library sources) how SIGINT was *generated* (through SetConsoleCtrlHandler), and that let me to a way to generate I didn't mean to suggest that you *should* use GenerateConsoleCtrlEvent, only that you could if you wanted to. I expect that GenerateConsoleCtrlEvent() can be called through the ctypes module, though that would make backporting the test to 2.4 a bit more difficult. Well, if there was general utility to that API, I would prefer exposing it in the nt module. It doesn't quite fit into kill(2), as it doesn't allow to specify a pid of the target process, so perhaps it doesn't have general utility. In any case, that would have to wait for 2.6. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
At 11:42 PM +0200 7/30/06, Martin v. Löwis wrote: Tony Nelson schrieb: You can use GenerateConsoleCtrlEvent to send Ctrl-C to all processes that share the console of the calling process. [...] Martin, your advice is usually spot-on, but I don't always understand it. Maybe using it here is just complicated. This was really just in response to your remark that you couldn't find a way to send Ctrl-C programmatically. I researched (in the C library sources) how SIGINT was *generated* (through SetConsoleCtrlHandler), and that let me to a way to generate [one.] Well, fine work there! I didn't mean to suggest that you *should* use GenerateConsoleCtrlEvent, only that you could if you wanted to. Hmm. Well, it would make the test possible on MSWindows as well as on OS's implementing alarm(2). If I figure out how to build Python on MSWindows, I might give it a try. I tried to get MSVC 7.1 via the .Net SDK, but it installed VS 8 instead, so I'm not quite sure how to proceed. I expect that GenerateConsoleCtrlEvent() can be called through the ctypes module, though that would make backporting the test to 2.4 a bit more difficult. Well, if there was general utility to that API, I would prefer exposing it in the nt module. It doesn't quite fit into kill(2), as it doesn't allow to specify a pid of the target process, so perhaps it doesn't have general utility. In any case, that would have to wait for 2.6. A Process Group ID is the PID of the first process put in it, so it's sort of a PID. It just means a collection of processes, probably more than one. It seems to be mostly applicable to MSWindows, and isn't a suitable way to implement a form of kill(2). I hope that the Socket Timeouts patch 1519025 can make it into 2.5, or 2.5.1, as it is a bug fix. As such, it would probably be better to punt the test on MSWindows than to do a tricky fancy test that might have its own issues. TonyN.:' mailto:[EMAIL PROTECTED] ' http://www.georgeanelson.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
At 7:23 PM -0400 7/30/06, Tony Nelson wrote: ... ...I tried to get MSVC 7.1 via the .Net SDK, but it installed VS 8 instead, so I'm not quite sure how to proceed. ... David Murmann suggested off-list that I'd probably installed the 2.0 .Net SDK, and that I should install the 1.1 .Net SDK, which is the correct one. Now I can try to build Python on MSWindows. TonyN.:' mailto:[EMAIL PROTECTED] ' http://www.georgeanelson.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
Tony Nelson schrieb: Hmm. Well, it would make the test possible on MSWindows as well as on OS's implementing alarm(2). If I figure out how to build Python on MSWindows, I might give it a try. I tried to get MSVC 7.1 via the .Net SDK, but it installed VS 8 instead, so I'm not quite sure how to proceed. The .NET SDK (any version) is not suitable to build Python. You really need VS 2003; if you don't have it anymore, you might be able to find a copy of the free version of the VC Toolkit 2003 (VCToolkitSetup.exe) somewhere. Of course, just for testing, you can also install VS Express 2005, and use the PCbuild8 projects directory; these changes should work the same under both versions. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
At 4:34 AM +0200 7/31/06, Martin v. Löwis wrote:
Tony Nelson schrieb:
Hmm. Well, it would make the test possible on MSWindows as well as on
OS's implementing alarm(2). If I figure out how to build Python on
MSWindows, I might give it a try. I tried to get MSVC 7.1 via the .Net
SDK, but it installed VS 8 instead, so I'm not quite sure how to proceed.
The .NET SDK (any version) is not suitable to build Python.
I do see the warning in the instructions about it not be an optimizing
compiler. I've managed to build python.exe and the rt.bat tests mostly
work -- 2 tests fail, test_popen, and test_cmd_line because of popen()
failing.
Hmm, actually, this might be a real problem with the MSWindows version of
posix_popen() in Modules/posixmodule.c. The path to my built python.exe is:
E:\Documents and Settings\Tony Nelson\My
Documents\Python\pydev\trunk\PCBuild\python.exe
(lots of spaces in it). It seems properly quoted in the test and when I do
it by hand, but in a call to popen() it doesn't work:
popen('E:\Documents and Settings\Tony Nelson\My
Documents\Python\pydev\trunk\PCBuild\python.exe -c import
sys;sys.version_info')
The returned file object repr resembles one that does work. If I just use
python.exe from within the PCBuild directory:
popen('python.exe -c import sys;sys.version_info')
I get the right version, and that's the only 2.5b2 python I've got, so the
built python must be working, but the path, even quoted, isn't accepted by
MSWindows XP SP2. Should I report a bug? It may well just be MSWindows
weirdness, and not something that posixmodule.c can do anything about.
OTOH, it does work from the command line. I'll bet I wouldn't have seen a
thing if I'd checked out to E:\pydev instead.
You really need VS 2003; if you don't have it anymore, you might be able
to find a copy of the free version of the VC Toolkit 2003
(VCToolkitSetup.exe) somewhere.
I really never had VS 2003. It doesn't appear to be on microsoft.com
anymore. I'm reluctant to try to steal a copy.
Of course, just for testing, you can also install VS Express 2005, and
use the PCbuild8 projects directory; these changes should work the
same under both versions.
I'll try that if I have any real trouble with the non-optimized python or
if you insist that it's necessary.
TonyN.:' mailto:[EMAIL PROTECTED]
' http://www.georgeanelson.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
At 12:39 AM -0400 7/31/06, Tony Nelson wrote:
popen('E:\Documents and Settings\Tony Nelson\My
Documents\Python\pydev\trunk\PCBuild\python.exe -c import
sys;sys.version_info')
Ehh, I must admit that I retyped that. Obviously what I typed would not
work, but what I used was:
python = '' + sys.executable + ''
popen(python + ' -c import sys;sys.version_info'
So there wasn't a problem with backslashes. I've also been using raw
strings. And, as I said, the file objects looked OK, with backslashes
where they should be. Sorry for the mistyping.
TonyN.:' mailto:[EMAIL PROTECTED]
' http://www.georgeanelson.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
At 12:58 AM -0400 7/31/06, Tony Nelson wrote:
At 12:39 AM -0400 7/31/06, Tony Nelson wrote:
popen('E:\Documents and Settings\Tony Nelson\My
Documents\Python\pydev\trunk\PCBuild\python.exe -c import
sys;sys.version_info')
Ehh, I must admit that I retyped that. Obviously what I typed would not
work, but what I used was:
python = '' + sys.executable + ''
popen(python + ' -c import sys;sys.version_info'
So there wasn't a problem with backslashes. I've also been using raw
strings. And, as I said, the file objects looked OK, with backslashes
where they should be. Sorry for the mistyping.
OK, I recognize the bug now. It's that quote parsing bug in MSWindows
(which I can find again if you want) which can be worked around by using an
extra quote at the front (and maybe also the back):
popen('E:\Documents ...
Not really a bug in Python at all.
TonyN.:' mailto:[EMAIL PROTECTED]
' http://www.georgeanelson.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Testing Socket Timeouts patch 1519025
I'm trying to write a test for my Socket Timeouts patch [1], which fixes signal handling (notably Ctl-C == SIGINT == KeyboarInterrupt) on socket operations using a timeout. I don't see a portable way to send a signal, and asking the test runner to press Ctl-C is a non-starter. A real signal is needed to interrupt the select() (or equivalent) call, because that's what wasn't being handled correctly. The bug should happen on the other platforms I don't know how to test on. Is there a portable way to send a signal? SIGINT would be best, but another signal (such as SIGALRM) would do, I think. If not, should I write the test to only work on systems implementing SIGALRM, the signal I'm using now, or implementing kill(), or what? [1] http://www.python.org/sf/1519025 TonyN.:' mailto:[EMAIL PROTECTED] ' http://www.georgeanelson.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
Tony Nelson [EMAIL PROTECTED] wrote: I'm trying to write a test for my Socket Timeouts patch [1], which fixes signal handling (notably Ctl-C == SIGINT == KeyboarInterrupt) on socket operations using a timeout. I don't see a portable way to send a signal, and asking the test runner to press Ctl-C is a non-starter. A real signal is needed to interrupt the select() (or equivalent) call, because that's what wasn't being handled correctly. The bug should happen on the other platforms I don't know how to test on. Is there a portable way to send a signal? SIGINT would be best, but another signal (such as SIGALRM) would do, I think. According to my (limited) research on signals, Windows signal support is horrible. I have not been able to have Python send signals of any kind other than SIGABRT, and then only to the currently running process, which kills it (regardless of whether you have a signal handler or not). If not, should I write the test to only work on systems implementing SIGALRM, the signal I'm using now, or implementing kill(), or what? I think that most non-Windows platforms should have non-braindead signal support, though the signal module seems to be severely lacking in sending any signal except for SIGALRM, and the os module has its fingers on SIGABRT. If someone is looking for a project for 2.6 that digs into all sorts of platform-specific nastiness, they could add actual signal sending to the signal module (at least for unix systems). - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
On Sat, 29 Jul 2006 14:38:38 -0700, Josiah Carlson [EMAIL PROTECTED] wrote: If someone is looking for a project for 2.6 that digs into all sorts of platform-specific nastiness, they could add actual signal sending to the signal module (at least for unix systems). Maybe I am missing something obvious, but what is necessary beyond os.kill()? What /would/ be useful is a complete sigaction wrapper, but that's a completely separate topic. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
At 2:38 PM -0700 7/29/06, Josiah Carlson wrote: Tony Nelson [EMAIL PROTECTED] wrote: I'm trying to write a test for my Socket Timeouts patch [1], which fixes signal handling (notably Ctl-C == SIGINT == KeyboarInterrupt) on socket operations using a timeout. I don't see a portable way to send a signal, and asking the test runner to press Ctl-C is a non-starter. A real signal is needed to interrupt the select() (or equivalent) call, because that's what wasn't being handled correctly. The bug should happen on the other platforms I don't know how to test on. Is there a portable way to send a signal? SIGINT would be best, but another signal (such as SIGALRM) would do, I think. According to my (limited) research on signals, Windows signal support is horrible. I have not been able to have Python send signals of any kind other than SIGABRT, and then only to the currently running process, which kills it (regardless of whether you have a signal handler or not). Hmm, OK, darn, thanks. MSWindows does allow users to press Ctl-C to send a KeyboardInterrupt, so it's just too bad if I can't find a way to test it from a script. If not, should I write the test to only work on systems implementing SIGALRM, the signal I'm using now, or implementing kill(), or what? I think that most non-Windows platforms should have non-braindead signal support, though the signal module seems to be severely lacking in sending any signal except for SIGALRM, and the os module has its fingers on SIGABRT. The test now checks hasattr(signal, 'alarm') before proceeding, so at least it won't die horribly. If someone is looking for a project for 2.6 that digs into all sorts of platform-specific nastiness, they could add actual signal sending to the signal module (at least for unix systems). Isn't signal sending the province of kill (2) (or os.kill()) in python)? Not that I know much about it. BTW, I picked SIGALRM because I could do it all with one thread. Reading POSIX, ISTM that if I sent the signal from another thread, it would bounce off that thread to the main thread during the call to kill(), at which point I got the willies. OTOH, if kill() is more widely available than alarm(), I'll give it a try, but going by the docs, I'd say it isn't. TonyN.:' mailto:[EMAIL PROTECTED] ' http://www.georgeanelson.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
