Thomas Heller <[EMAIL PROTECTED]> added the comment:

Ok, here is the plan (basically Armin's proposal):

ctypes maintains a gloabl, but thread-local, variable that contains an error 
number;
called 'ctypes_errno' for this discussion.

ctypes.set_errno(value) copies 'value' into ctypes_errno, and returns the old 
value.
ctypes.get_errno() returns the current ctypes_errno value.

Foreign functions created with CDLL(..., use_errno=True), when called, copy
the ctypes_errno value into the real errno just before they are called, and copy
the real errno value into ctypes_errno. The 'use_errno' parameter defaults to 
False,
in this case ctypes_errno is not touched.

The same scheme is implemented on Windows for GetLastError() and SetLastError(),
the variable is named 'ctypes_LastError', and the CDLL and WinDLL optional 
parameter
is named 'use_LastError', and also defaults to False.

Armin Rigo schrieb:
> (Another note: the C-level errno and the TLS copy should also be
> synchronized when the C code invokes a Python callback.)

Not sure what this is for, please proofread the patch when I attach one.
Even better, someone could supply test-cases for all this, either
as executable code or as prosa.

> (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...)

Since the new behaviour will only be invoked when use_errno or use_LastError
is used, they should be able to still use their workarounds.

_______________________________________
Python 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

Reply via email to