[Pythonmac-SIG] Python crash!
bob at redivi.com
Thu Oct 16 13:47:58 EDT 2003
On Thursday, Oct 16, 2003, at 13:37 America/New_York, Marcus H.
> On Thursday, October 16, 2003, at 12:26 PM, Bob Ippolito wrote:
>> On Thursday, Oct 16, 2003, at 13:15 America/New_York, Marcus H.
>> Mendenhall wrote:
>>> This is the first one of these I have seen in a while. I was
>>> running a program in the python IDE
>>> The only slightly unusual thing about the program is that I was
>>> using signal handlers, which I haven't done a lot of before. Here
>>> is the program, for reference:
>>> Anyone want to try to trace this down?
>> Python is not very good at signal handlers.. try not to use them,
>> especially not in the IDE. They're just asking for trouble because
>> signal handlers cause a condition that the interpreter isn't very
>> capable of coping with. I would suggest attempting to do this in
>> another way (i.e. using network sockets to ask your program to open a
>> new file or quit).
> Do you think the problem is specific to the IDE? Has trouble been
> actually seen outside of the IDE, or is it just a queasy feeling there
> that the Python interpreter is structured unsafely somewhere for
> This program normally runs as a daemon, and I was just testing it in
> the IDE. Maybe that is why I have never seen the issue before?
> I may think about switching this to a different mechanism if there
> really is a reliability issue, even without the IDE, since I am
> starting work on a block of code I want to be VERY reliable.
The reason it's particularly problematic is that it doesn't really
handle the signals when they happen, it puts the signal handler next in
the bytecode queue. I've had problems with it as well, when I was in C
code when it happened. This is probably what happened with you in the
IDE. Chances are, if you're not using a C runloop (IDE or whatever)
then you'll be OK.. but it may not be worth it.
Personally, I would move it to another mechanism, besides.. using
sockets instead of signals would get you better flexibility (remote
control if you want it) and win32 compatibility (if you ever need it).
More information about the Pythonmac-SIG