This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Rhamphoryncus
Recipients
Date 2006-09-29.21:09:49
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=12364

I'm concerned about the interface to
PyOS_InterruptOccurred().  The original version peeked ahead
for only that signal, and handled it manually.  No need to
report errors.  The new version will first call arbitrary
python functions to handle any earlier signals, then an
arbitrary python function for the interrupt itself, and then
will not report any errors they produce.  It may not even
get to the interrupt, even if one is waiting.

I'm not sure PyOS_InterruptOccurred() is called when
arbitrary python code is acceptable.  I suspect it should be
dropped entierly, in favour of a more robust API.

Otoh, some of it appears quite crufty.  One version in
intrcheck.c lacks a return statement, invoking undefined
behavior in C.

One other concern I have is that signalmodule.c should never
been unloaded, if loaded via dlopen.  A delayed signal
handler may reference it indefinitely.  However, I see no
sane way to enforce this.
History
Date User Action Args
2007-08-23 15:54:43adminlinkissue1564547 messages
2007-08-23 15:54:43admincreate