Eric Blake <ebb9 <at> byu.net> writes: > > Eric Blake <ebb9 <at> byu.net> writes: > > > One improvement possible for fdopendir is that > > if fchdir is being emulated by gnulib, we can do a query into the fchdir > > metadata table to retrieve the directory name associated with an fd, rather > > than having to go through save_cwd/fchdir/opendir/restore_cwd. > > Here's two patches for that, to be applied on top of fchdir.
Notice that this changes the status of fdopendir - whereas it was previously non-multithread safe and could call _exit, the mingw version of fdopendir is now threadsafe and avoids _exit. If this property is desirable, we could consider a followup that makes all platforms that lack fdopendir and decent /proc/self/fd/n support use the trick of fchdir's metadata mapping between directory fds and their names. It won't, however, solve the problem that our openat() emulation is not threadsafe; and although we could use the cached directory name to construct an appropriate absolute name to avoid our current fchdir() usage in the openat() replacement, that would have O(n^2) instead of O(n) performance and suffer from ENAMETOOLONG problems. So I guess the question is whether a thread-safe fdopendir is worthwhile for all platforms, regardless of whether all the gnulib clients of fdopendir are already non-thread-safe for other reasons. -- Eric Blake
