[Python-Dev] Py_END_ALLOW_THREADS and GetLastError()
Currently on Windows, Py_END_ALLOW_THREADS can have the side effect of
resetting the windows error code returned by GetLastError().
There is a number of cases, particularly in posixmodule, with a pattern like:
Py_BEGIN_ALLOW_THREADS
result = FindNextFile(hFindFile, &FileData);
Py_END_ALLOW_THREADS
/* FindNextFile sets error to ERROR_NO_MORE_FILES if
it got to the end of the directory. */
if (!result && GetLastError() != ERROR_NO_MORE_FILES) {
That doesn´t work. (This particular site is where I noticed the problem,
running the testsuite in a debug build).
Now, the thread swith macro does take care to preserve "errno", but not the
windows system error. This is easy to add, but it requires that windows.h be
included by ceval.c and pystate.c
The alternative fix is to find all these cases and manually preserve the error
state, or query it right after the function call if needed.
Any preferences?
Kristján
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Getting importlib into the standard library for 3.1
Brett Cannon wrote: OK, since no one has really said anything, I am going to assume no one has issues with importlib in terms of me checking it in or choosing a name for it (I like importlib more than imp so I will probably stick with that). So I will do some file renaming and reorganization, get the code set up to be run by regrtest, and then check the code in! I am going to set PyCon as a hard deadline such that no matter how much more file churn I have left I will still check it into py3k by then (along with importlib.import_module() into 2.7). +1 :-) Michael On Thu, Jan 8, 2009 at 11:06, Brett Cannon wrote: My work rewriting import in pure Python code has reached beta. Basically the code is semantically complete and as backwards-compatible as I can make it short of widespread testing or running on a Windows box. There are still some tweaks here and there I want to make and an API to expose, but __import__ works as expected when run as the import implementation for all unit tests. Knowing how waiting for perfection leads to never finishing, I would like to start figuring out what it will take to get the code added to the standard library of 3.1 with hopes of getting the bootstrapping stuff done so that the C implementation of import can go away in 3.1 as well. I see basically three things that need to be decided upfront. One, does anyone have issues if I check in importlib? We have typically said code has to have been selected as best-of-breed by the community first, so I realize I am asking for a waiver on this one. Two, what should the final name be? I originally went with importlib since this code was developed outside of the trunk, but I can see some people suggesting using the imp name. That's fine although that does lead to the question of what to do with the current imp. It could be renamed _imp, but then that means what is currently named _importlib would have to be renamed to something else as well. Maybe imp._bootstrap? Plus I always viewed imp as the place where really low-level, C-based stuff lived. Otherwise importlib can slowly subsume the stuff in imp that is still useful. Three, there are still some structural changes to the code that I want to make. I can hold off on checking in the code until these changes are made, but as I said earlier, I know better than to wait forever for perfection. And because I know people will ask: no, I do not plan to backport all the code to 2.7. I want this to be a carrot to people to switch to 3.x. But I will backport the import_module function I wrote to 2.7 so people do have that oft-requested feature since it is a really simple bit of Python code. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py_END_ALLOW_THREADS and GetLastError()
Kristján Valur Jónsson wrote:
> Currently on Windows, Py_END_ALLOW_THREADS can have the side effect of
> resetting the windows error code returned by GetLastError().
>
> There is a number of cases, particularly in posixmodule, with a pattern
> like:
>
> Py_BEGIN_ALLOW_THREADS
>
> result = FindNextFile(hFindFile, &FileData);
>
> Py_END_ALLOW_THREADS
>
> /* FindNextFile sets error to ERROR_NO_MORE_FILES if
>
>it got to the end of the directory. */
>
> if (!result && GetLastError() != ERROR_NO_MORE_FILES) {
>
>
>
> That doesn´t work. (This particular site is where I noticed the
> problem, running the testsuite in a debug build).
>
> Now, the thread swith macro does take care to preserve „errno“, but not
> the windows system error. This is easy to add, but it requires that
> windows.h be included by ceval.c and pystate.c
>
> The alternative fix is to find all these cases and manually preserve the
> error state, or query it right after the function call if needed.
>
> Any preferences?
Please see http://bugs.python.org/issue4906 :-)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py_END_ALLOW_THREADS and GetLastError()
On Saturday 10 January 2009 12:29:47 Kristján Valur Jónsson wrote:
> Currently on Windows, Py_END_ALLOW_THREADS can have the side effect of
> resetting the windows error code returned by GetLastError(). There is a
> number of cases, particularly in posixmodule, with a pattern like:
> Py_BEGIN_ALLOW_THREADS
> result = FindNextFile(hFindFile, &FileData);
> Py_END_ALLOW_THREADS
> /* FindNextFile sets error to ERROR_NO_MORE_FILES if
>it got to the end of the directory. */
> if (!result && GetLastError() != ERROR_NO_MORE_FILES) {
>
> That doesn´t work. (This particular site is where I noticed the problem,
> running the testsuite in a debug build). Now, the thread swith macro does
> take care to preserve "errno", but not the windows system error. This is
> easy to add, but it requires that windows.h be included by ceval.c and
> pystate.c The alternative fix is to find all these cases and manually
> preserve the error state, or query it right after the function call if
> needed. Any preferences?
Well, that's what you get for using globals and exactly that is the reason why
their use is generally discouraged. My preference would be to fix all cases
where there is an intervening call after the call that set errno to first
preserve that state. As a short term fix, I would add a workaround to
Py_END_ALLOW_THREADS though, both for errno and win32's GetLastError().
Generally, I would discourage non-local errno use. My motivation is that MS
Windows CE simply doesn't have errno and MS Windows in general often uses
different ways to signal errors, so not using it would restrict the
conditionally compiled code further. Especially in the math module, I have no
idea yet how to port that in a way that is still at least remotely clean and
maintainable because errno is used everywhere there. Translating the errno
value to a Python error directly after the failed call would help immensely.
just my two embedded cents
Uli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py_END_ALLOW_THREADS and GetLastError()
> Well, that's what you get for using globals Please do take a look at the issue at hand before pointing fingers. First, GetLastError() isn't a really a global (and neither is errno); they are both thread-local. Next, there is really no choice to use or not use errno - if you want to find out what the error is that has occurred, you *have* to look at errno. Finally, in the case of Py_END_ALLOW_THREADS, errno/GetLastError is typically read right after the system call. However, you can't raise the Python exception before Py_END_ALLOW_THREADS (which you seem to suggest as a solution), since we must not call Python APIs without holding the GIL. > Generally, I would discourage non-local errno use. My motivation is that MS > Windows CE simply doesn't have errno and MS Windows in general often uses > different ways to signal errors, so not using it would restrict the > conditionally compiled code further. That sounds like an unrelated issue to the one at hand. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py_END_ALLOW_THREADS and GetLastError()
On Saturday 10 January 2009 15:11:16 Martin v. Löwis wrote: > > Well, that's what you get for using globals > > Please do take a look at the issue at hand before pointing fingers. I'm really sorry if this sounded like I was accusing someone, that was not my intention. Uli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Meet your next release manager: Benjamin Peterson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 9, 2009, at 8:21 PM, Aahz wrote: On Fri, Jan 09, 2009, Barry Warsaw wrote: To that end, I'm happy to say that Benjamin Peterson will be the release manager for Python 2.7 and 3.1. I will be mentoring him through the process, but it'll be his ball of snake wax. Please join me in helping him make the 2.7 and 3.1 releases as great as 2.6 and 3.0! Great news! How many cases of beer did you feed him before he agreed? Anthony and I have just had so much fun whitewashing the last few releases, we just couldn't in good conscious keep it to ourselves! Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSWkqeHEjvBPtnXfVAQLOVgP7BKxYMplrBEu71AqwrhdBcYdFNV+936/7 WUUm4FXwkB2sTnfuoEkQH/N195PDUIAi2MAE6sbfkVRyl/qrVnAEsa7bQ9Ss8a6J wu9ouCDQzAqqlyXzxjPUKOdJTpteALE6IhYBMDUDIJDt4BKX/CBXctFCZpEoE50Z lQVY28m21Xg= =WkhB -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Meet your next release manager: Benjamin Peterson
On Sat, Jan 10, 2009, Barry Warsaw wrote: > On Jan 9, 2009, at 8:21 PM, Aahz wrote: >> On Fri, Jan 09, 2009, Barry Warsaw wrote: >>> >>> To that end, I'm happy to say that Benjamin Peterson will be the >>> release manager for Python 2.7 and 3.1. I will be mentoring him >>> through the process, but it'll be his ball of snake wax. Please >>> join me in helping him make the 2.7 and 3.1 releases as great as 2.6 >>> and 3.0! >> >> Great news! How many cases of beer did you feed him before he >> agreed? > > Anthony and I have just had so much fun whitewashing the last few > releases, we just couldn't in good conscious keep it to ourselves! ^ That proves my point, I think. ;-) -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Meet your next release manager: Benjamin Peterson
Aahz wrote: > On Sat, Jan 10, 2009, Barry Warsaw wrote: >> On Jan 9, 2009, at 8:21 PM, Aahz wrote: >>> On Fri, Jan 09, 2009, Barry Warsaw wrote: To that end, I'm happy to say that Benjamin Peterson will be the release manager for Python 2.7 and 3.1. I will be mentoring him through the process, but it'll be his ball of snake wax. Please join me in helping him make the 2.7 and 3.1 releases as great as 2.6 and 3.0! >>> Great news! How many cases of beer did you feed him before he >>> agreed? >> Anthony and I have just had so much fun whitewashing the last few >> releases, we just couldn't in good conscious keep it to ourselves! > ^ > That proves my point, I think. ;-) No, that demonstrates that while he's happy to share the release management around Barry has been keeping the beer all to himself. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
