Message184164
On 14/03/2013 1:00pm, Martin v. Löwis wrote:
> That's why I was asking for an actual patch. The proposed change may
> well not be implementable. If os.open continues to create CRT handles,
> a way needs to be found to get a CRT handle that as the
> FILE_SHARE_DELETE bit set.
The patch *does* create CRT fds from win32 handles by using
msvcrt.open_osfhandle().
One other issue is that I do not know of a way to determine the current
umask without temporarily changing it, causing a thread-race.
In the end I am not sure it is worth the hassle. (But maybe it would be
a good idea to add test.support.open() using FILE_SHARE_DELETE and
test.support.unlink() to make the testsuite more resilient to
"Permission Denied" errors.)
> An alternative approach could be that os.open stops creating CRT
> handles, and directly uses OS handles. The problem with that is that
> stdin/stdout/stderr would stop being 0/1/2, which is not acceptable.
> An alternative solution to that could be that we introduce a notion
> of "python io handles", parallel, but indepedendent from CRT handles.
> And so on.
http://bugs.python.org/issue12939 has C implementations of _io.WinFileIO
and _io.openhandle() which are equivalents for _io.FileIO and os.open()
which use "native" Windows handles. |
|
Date |
User |
Action |
Args |
2013-03-14 14:37:13 | sbt | set | recipients:
+ sbt, loewis, ncoghlan, pitrou, dabrahams, piotr.dobrogost |
2013-03-14 14:37:13 | sbt | link | issue15244 messages |
2013-03-14 14:37:12 | sbt | create | |
|