> 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...