On Jun 24, 2007, at 2:19 PM, Martin v. Löwis wrote: > I don't see why it is a requirement to *open* the file in > non-inheritable mode. Why is not sufficient to *modify* > an open file to have its handle non-inheritable in > an easy and platform-independent way?
Threads. Consider that you may fork a process on one thread right between the calls to open() and fcntl(F_SETFD, FD_CLOEXEC) on another thread. The only way to be safe is to open the file non-inheritable to start with. Now, it is currently impossible under linux to open a file descriptor noninheritable, but they're considering adding that feature (I don't have the thread-refs on me, but it's actually from the last month). The issue is that there's a *bunch* of syscalls that open FDs: this feature would need to be added to all of them, not only "open". It's possible that it makes sense for python to provide "as good as possible" an implementation. At the least, putting the fcntl call in the same C function as open would fix programs that don't open files/ spawn processes outside of the GIL protection. But, like the kernel, this feature then ought to be provided for all APIs that create file descriptors. >>> With that API, it would be possible to provide cross-platform >>> access to the close-on-exec flag. Applications interested in setting >>> it could then set it right after opening the file. >> >> YES - that's exactly why I proposed an open_noinherit function. > > I think I missed that proposal. What would that function do? > > If you propose it to be similar to the open() function, I'd > be skeptical. It's not possible to implement that in thread-safe > way if you use SetHandleInformation/ioctl. Now I'm confused: are you talking about the same thread-safety situation as I described above? If so, why did you ask why it's not sufficient to modify a handle to be non-inheritable? James _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com