Re: fchdir on mingw

[Eric Blake]

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