Re: [RFC] Add pthread_detach_pwd call.

[Rich Felker <dalias at aerifal dot cx>]

On Sun, Oct 20, 2013 at 07:41:09PM +0200, OndÅej BÃlka wrote:
> Hi,
> 
> One of problematic parts of threading is working directory. As it is
> global a changing it is problematic. Particulary when there is a third
> party library that does this without multithreading in mind.
> 
> I got idea how users could fix this without much effort. It is that we
> implement a pthread_detach_pwd call which will cause all subsequent
> queries/changes in thread be resolved by using thread local variable.
> 
> Possible disadvantage is that this would make open/fopen more complicated.

There is already a clean, portable way to achieve the exact same
thing: the *at functions. Your proposal would have very confusing
semantics: for example, when a thread with detached pwd creates a new
thread, does the new thread:

(a) inherit a copy of the creating thread's pwd?
(b) become attached to the creating thread's pwd?
(c) start with the process's pwd?

It's not clear at all to me which would be the right behavior from a
standpoint of being transparent to library code. Then there are even
worse questions, like what happens when you create a POSIX timer with
SIGEV_THREAD handler.

In short, this is just completely the wrong direction to go in.
Changing the working directory during the process's lifetime should be
considered a legacy feature; it already has lots of problems. Modern
code should work with a mix of absolute pathnames and *at functions,
and should treat the pwd as a read-only argument to the program.

Rich