On Sun, Jun 24, 2007 at 10:48:30PM +0200, "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. > > No, that's not the only safe way. The application can synchronize the > threads, and prevent starting subprocesses during critical regions. > Just define a subprocess_lock, and make all of your threads follow > the protocol of locking that lock when either opening a new file, > or creating a subprocess.
The problem here is that sitting in accept() becomes a critical section. While a thread is sitting in that call, no other thread could start a subprocess. A multithreaded server which uses a 1-thread-per-request model wouldn't be possible, at least not in a reasonable amount of comprehensible code. > > 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". > > Right. That is what makes it difficult inherently on the API level. LWN has had good coverage of the discussion: http://lwn.net/Articles/237722/ Ross _______________________________________________ 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
