>> Or, you could simply write your threaded applications to always pass
>> fully rooted paths. Seems like a much simpler change to me.
>
>``You could simply write your apps so that ...'' is not always that
>simple in the real world. Within the portions of the application that
>you write yourself, you can stick to arbitrary conventions, but there
>may be third-party components, some of which you don't have source code
>to, others which would be hard to modify.
Either they're thread-safe, or they're not. APIs which pass pathnames
can be threadsafe in the presence of chdir() calls only if they're fully
rooted. If you don't know if your third-party components use chdir(),
assume they do and protect yourself. If the component claims to be
threadsafe, then it already uses rooted paths; if it doesn't do so, then
the claim is patently false.
This isn't an "arbitrary convention" I suggested. It's how to write code
in the presence of other threads which could be doing *anything*.
>How do you know that the directory traversal function ftw() doesn't
>use internally use chdir and relative references, for instance? What
>if two or more threads use this library function at the same time?
If ftw() is marked as thread-safe, then it cannot screw with chdir() and
must support more than one thread using it at once. If it is not marked
as thread-safe, then all bets are off and you, the programmer, are
responsible for serialization; not only do you have to prevent multiple
threads from invoking ftw() simultaneously, but you are also required to
ensure you don't call chdir() while ftw() is doing its thing.
There's nothing new in what I'm saying; the design of Unix threading
APIs forces all of this on you. If you want to *change* those APIs, feel
free to implement it and then propose it in a future revision of the
standard. But app developers should have been writing this way from the
day threading was introduced to Unix.
>Full paths are a disadvantage for another reason: platforms impose
>limitations on how long a path you can specify in one call. E.g.
>I think on Linux, I think it's the size of a page, so 4096-1 bytes
>on IA-32. If you pass a string longer than that to open() and other
>functions, they will bail with ENAMETOOLONG. Thus a filesystem could
>have areas that are only reachable by a combination of chdir() and
>relative paths.
Fortunately, symbolic links are a complete solution to this. Unless the
limitation is in Linux's ability to handle long paths inside the kernel
where symlink expansion occurs, rather than through the system call
interface. In that case, symlinks don't help, and you've encountered a
Quality Of Implementation issue.
And you can programmatically access those deep parts of the filesystem,
too; in a multithreaded application, you have to apply the necessary
level of rigor as a developer. I could probably construct an argument
that such a scenario is really outside the scope of the standard,
anyway. It shows up once in a blue moon (usually due to some runaway
shell script creating a too-deep hierarchy by accident) and shouldn't be
the design focus of an operating system interface.
|