[issue13285] signal module ignores external signal changes
Vilya Harvey added the comment: Petri: yes, that what I was suggesting. Charles-François: I'm certainly open to alternatives. Unless I've overlooked something though, the problem is that no workaround is possible at the moment. BTW this came up in the context of a customer script for the software I work on, so it's not just a theoretical problem - at least, not for me. :-) I guess another solution would be methods to save and restore the native signal handers, e.g. savesignal(signum) & restoresignal(signum). That wouldn't entirely solve the problem - if someone called setsignal() before calling savesignal(), they'd end up in the same situation - but it would at least permit a workaround. -- ___ Python tracker <http://bugs.python.org/issue13285> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13285] signal module ignores external signal changes
Vilya Harvey added the comment:
Could it return an opaque wrapper object, rather than just the raw address?
Something like:
typedef struct _PyNativeSignalHandler {
PyObject_HEAD
sighandler_t handler_func;
} PyNativeSignalHandler;
where the type object doesn't expose any way to read or manipulate the
handler_func. Would that work, do you think?
--
___
Python tracker
<http://bugs.python.org/issue13285>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13285] signal module ignores external signal changes
Changes by Vilya Harvey : -- title: signal module in ignores external signal changes -> signal module ignores external signal changes ___ Python tracker <http://bugs.python.org/issue13285> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13285] signal module in ignores external signal changes
New submission from Vilya Harvey : The signal module is oblivious to any changes to the set of installed signal handlers which occur outside of the module. This can happen when a native module changes a signal handler, or when the python interpreter is embedded in another program which installs its own signal handlers. In this case, saving and restoring a signal handler through python doesn't work correctly. For example, if the SIGINT handler is set externally after the signal module is initialised, the following code will replace the external signal handler with python's default_int_handler: handler = signal.getsignal(signal.SIGINT) signal.signal(signal.SIGINT, handler) So it's impossible to reliably save and restore signal handlers through python when they can also be changed outside the python interpreter. Also, if there's a signal handler installed before the module is initialised, signal.getsignal() will return None for it - making it impossible to restore the correct handler after disabling it. The reason is that the signal module only checks for existing handlers when it's initialised. The results get stored in the Handlers array, which is then used by all subsequent calls to signal.getsignal(). There are no further checks to see whether the native signal handlers have changed. -- messages: 146553 nosy: vilya priority: normal severity: normal status: open title: signal module in ignores external signal changes type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue13285> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1791] The Library Reference still refers to the old bug tracker.
New submission from Vilya Harvey: The page at http://docs.python.org/lib/about.html refers people to the old SourceForge bug tracker, rather than bugs.python.org. -- messages: 59707 nosy: vilya severity: normal status: open title: The Library Reference still refers to the old bug tracker. versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1791> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1790] xmlrpclib ServerProxy page has out-of-date content
New submission from Vilya Harvey: The page at 'http://docs.python.org/lib/serverproxy-objects.html' contains the following text which should be removed as it's (a) not especially relevant; and (b) out of date: "Introspection methods are currently supported by servers written in PHP, C and Microsoft .NET. Partial introspection support is included in recent updates to UserLand Frontier. Introspection support for Perl, Python and Java is available at the XML-RPC Hacks page." In particular: Python has built in introspection support now; and the URL for the XML-RPC hacks page returns a 404 error. -- components: Documentation messages: 59706 nosy: vilya severity: normal status: open title: xmlrpclib ServerProxy page has out-of-date content __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1790> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
