I discovered an issue on Mac OS X that seems to relate to signal handling. I have a C binding in which I call the standard tmpfile() function. After calling it, I can't break Python anymore with CTRL-C.
Investigating the Darwin source code for tmpfile() (and FreeBSD, they are the same) , I found that the function is mucking with the signals:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/tmpfile.c?rev=1.9&a...
Is this considered a Python issue, or an OS issue? I ran a simple test against the interrupt signal, which didn't show any wrong behavior:
static void intcatcher(int sig) { printf("Interrupt catched\n"); exit(1); } int main(int argc, char **argv) { signal(SIGINT, intcatcher); printf("Press CTRL-C to interrupt...\n"); tmpfile(); while (1) ; return 0; }
But with my threaded Python code, SIGINT doesn't work anymore after my binding has called tmpfile().
Florent
Florent Pillet fpillet@gmail.com writes:
I discovered an issue on Mac OS X that seems to relate to signal handling. I have a C binding in which I call the standard tmpfile() function. After calling it, I can't break Python anymore with CTRL-C.
Investigating the Darwin source code for tmpfile() (and FreeBSD, they are the same) , I found that the function is mucking with the signals:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/tmpfile.c?rev=1.9&a...
Is this considered a Python issue, or an OS issue?
Um, I don't know. That function certainly looks like it's trying to pt the signal mask back.
I ran a simple test against the interrupt signal, which didn't show any wrong behavior:
static void intcatcher(int sig) { printf("Interrupt catched\n"); exit(1); } int main(int argc, char **argv) { signal(SIGINT, intcatcher); printf("Press CTRL-C to interrupt...\n"); tmpfile(); while (1) ; return 0; }
But with my threaded Python code, SIGINT doesn't work anymore after my binding has called tmpfile().
Oh, threads.
Which version of Python are you using?
Cheers, mwh
On 07/07/05, Michael Hudson mwh@python.net wrote:
But with my threaded Python code, SIGINT doesn't work anymore after my binding has called tmpfile().
Oh, threads.
Which version of Python are you using?
2.3.5, the one that ships with Mac OS X 10.4. I have a 2.4.x install somewhere, I'll give it a go. But you're right, it's probably because of threads. Now I'm trying to determine whether this is a Python bug or a Mac OS X bug...
Florent
Florent Pillet fpillet@gmail.com writes:
On 07/07/05, Michael Hudson mwh@python.net wrote:
But with my threaded Python code, SIGINT doesn't work anymore after my binding has called tmpfile().
Oh, threads.
Which version of Python are you using?
2.3.5, the one that ships with Mac OS X 10.4. I have a 2.4.x install somewhere, I'll give it a go.
Please do. If my guess as to what's going on is right, you won't have the problem.
But you're right, it's probably because of threads.
You *may* be able to work around this by only calling tmpfile on the main thread (just a guess).
Now I'm trying to determine whether this is a Python bug or a Mac OS X bug...
Well, again assuming my guess is right, it's probably an OS X bug, but really threads vs signals issues are enormously subtle and frequently messed up.
Python 2.4 is much less vulnerable to such cock ups.
Cheers, mwh
On Monday 11 July 2005 19:32, Michael Hudson wrote:
Well, again assuming my guess is right, it's probably an OS X bug, but really threads vs signals issues are enormously subtle and frequently messed up.
I think mwh meant to say "threads vs signals is a platform-dependant trail of misery, despair, horror and madness".
Python 2.4 is much less vulnerable to such cock ups.
Note that the underlying platform issues are still there, it's just that Python itself is much less likely to lose on these issues. This is also probably only true for mainstream operating systems - for the more niche ones like HP/UX or Irix, there's quite probably still issues hanging around. These are unlikely to get fixed unless someone who cares about these platforms is willing to spend a lot of time working on it. At one point, I was spending some time on this (using the DEC^WCompaq^WHP "testdrive" systems), but I stopped caring about them quite a while ago now. Too much pain, for zero gain for me.
-
Anthony Baxter -
Florent Pillet -
Michael Hudson