Message51153
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. |
|
Date |
User |
Action |
Args |
2007-08-23 15:54:43 | admin | link | issue1564547 messages |
2007-08-23 15:54:43 | admin | create | |
|