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: OndÅej BÃlka <neleai at seznam dot cz>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 21 Oct 2013 08:37:18 +0200
- Subject: Re: [RFC] Add pthread_detach_pwd call.
- Authentication-results: sourceware.org; auth=none
- References: <20131020174109 dot GA17943 at domone dot podge> <20131020222505 dot GK20515 at brightrain dot aerifal dot cx>
On Sun, Oct 20, 2013 at 06:25:05PM -0400, Rich Felker wrote:
> 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:
>
Could you browse around 50000 open source libaries and rewrite them with
at functions?
> (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?
>
A copy which is sanest.
> 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.
>
A new thread will use pwd as default.
A complexity is there but this makes reduces it versus original state
instead of useless whining to use at functions.
> 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
--
electromagnetic radiation from satellite debris