Armin Rigo <[EMAIL PROTECTED]> added the comment: > However, even the TLS copy of errno may change because of this, > if the finalizer of some object invokes ctypes, right?
Yes, it's annoying, but at least the Python programmer has a way to fix this problem: he can save and restore the TLS copy of errno around the call to ctypes done in the finalizer, using get_errno()/set_errno(). This matches what a C programmer would have to do if he wanted to write, say, a debugging function that can be called from anywhere including between an OS call and the following check for errno. (Another note: the C-level errno and the TLS copy should also be synchronized when the C code invokes a Python callback.) In PyPy, when creating and using our own internal FFI, we started by having a pair of functions that could directly read or change the C-level errno. Then we ran into various troubles (e.g. just stepping through the Python code in a debugger messes things up because of the debugger's own input/output) and finally reached the design I propose here. (Admittedly PyPy's internal FFI is a bit more low-level than ctypes, so maybe it's more appropriate for ctypes to use a higher-level approach that a return value checker.) (A related issue that we may or may not care about: it's more than likely that various people have already come up with various workarounds to handle errno, and these workarounds will probably stop working after ctypes is changed...) __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1798> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
