Charles-Francois Natali <neolo...@free.fr> added the comment: > I wonder whether the Java people are simply unaware of the potential problem? > Or perhaps they have checked the Linux and Solaris implementations of > readdir() > and confirmed that it is in fact safe on those platforms. Even if this is the > case, I would be wary of doing things the same way - there's no guarantee that > the implementation won't change out from underneath us.
The problem is not so much readdir: if you look at the source code (http://fxr.googlebit.com/source/lib/libc/gen/readdir.c), it doesn't do much apart from locking a mutex private to the related DIR *, so as long as you pass it a DIR * not referenced elsewhere (which would be the case since it would call opendir between the fork and exec), it should be ok. The man page (http://pubs.opengroup.org/onlinepubs/007908799/xsh/readdir.html) also makes it clear: """After a call to fork(), either the parent or child (but not both) may continue processing the directory stream using readdir(), rewinddir() or seekdir(). If both the parent and child processes use these functions, the result is undefined.""" The problem is more with opendir, which needs to allocate memory for the struct dirent before calling getdents syscall. I agree with you, we should definitely favor correctness over efficiency. As for the other approach, I'm not aware of any portable way to determine if a program is multi-threaded. Also, as noted by Victor, there might be room for some subtle races (Python-registered signal handlers are called synchronously from the main eval loop with the GIL held, so I don't think there should be a problem there, but you might have a problem with C-extension registered signal handlers). Finally, looking at this thread http://lists.freebsd.org/pipermail/freebsd-hackers/2007-July/021132.html, it seems that some closefrom implementations are definitely not async-safe, which is a pity... ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8052> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
