[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fchdir on mingw
From: |
Eric Blake |
Subject: |
Re: fchdir on mingw |
Date: |
Mon, 31 Aug 2009 23:38:45 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
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