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: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 21 Oct 2013 11:38:17 -0400
- 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> <5264FD5D dot 6040605 at redhat dot com> <20131021121336 dot GA23647 at domone dot podge>
On Mon, Oct 21, 2013 at 02:13:36PM +0200, OndÅej BÃlka wrote:
> On Mon, Oct 21, 2013 at 12:09:33PM +0200, Florian Weimer wrote:
> > On 10/21/2013 12:25 AM, Rich Felker wrote:
> >
> > >There is already a clean, portable way to achieve the exact same
> > >thing: the *at functions.
> >
> > fsetxattrat is missing, though. Probably more.
> >
> > I also don't see how we can actually implement something like
> > pthread_detach_pwd without adding and awful lot of wrappers. It's
> > certainly not just open and fopen, but anything that expects a path
> > name.
> >
> I expected that there is only limited number of primitives that access
> internal structure.
I think you'll find there are pretty many; at least 20-30 'primitive'
(i.e. not built upon simpler ones) functions take filename arguments,
and for these functions, trivial syscall wrappers would be replaced
with moderately-complex logic using the corresponding *at functions
and a thread-local pwd file descriptor.
BTW another issue is what should happen on fork and exec (or
posix_spawn). Library code that expects external programs it runs to
inherit the pwd it sees could be badly messed up if the child
inherited the pwd of the parent process rather than the calling
thread, but I suspect there are cases where the opposite behavior
could also mess things up.
Rich