This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Add pthread_detach_pwd call.
- From: Rich Felker <dalias at aerifal dot cx>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: libc-alpha at sourceware dot org
- Date: Sun, 20 Oct 2013 18:25:05 -0400
- Subject: Re: [RFC] Add pthread_detach_pwd call.
- Authentication-results: sourceware.org; auth=none
- References: <20131020174109 dot GA17943 at domone dot podge>
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