And you can still get there, even in a multithreaded app. If your app is
knowingly doing this kind of thing, it can just as "knowingly" deal with
the fact that fchdir() is being called and protect itself accordingly.
Are you guys seriously suggesting a new family of API calls (one for
every call that takes a pathname) to specify the directory to which a
relative path is in fact relative simply to handle some very obscure
corner cases that can't be addressed by the use of absolute paths?
-----Original Message-----
From: Marcus Brinkmann [mailto:yyyyyyyyyyyyyyyy@xxxxxxxxxxxxxxxxxx]
Sent: Monday, August 04, 2003 1:07 PM
To: s lurndal
Cc: Jason Zions; Kaz Kylheku; Alexander Terekhov;
yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx; yyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: Re: thread-private working directory
On Mon, Aug 04, 2003 at 11:44:12AM -0700, s lurndal wrote:
> >
> > Or, you could simply write your threaded applications to always pass
> > fully rooted paths. Seems like a much simpler change to me.
>
> The performance of such an application will, of course, be
> significantly worse than one which used per-thread or per-context
> current working directories due to the need to traverse the full
> pathname on each pathname-based operation, even with aggressive DNLC
> caching by the operating system.
It might not even be possible, for example if the current working
directory is not accessible from the root directory:
mkdir ("bar");
chdir ("bar");
rmdir ("../bar");
With fchdir you can actually switch between such inaccessible
directories.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org
yyyyyy@xxxxxxx
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
yyyyyyyyyyyyyyyy@xxxxxxxxxxxxxxxxxx
http://www.marcus-brinkmann.de/
|