[RFC] Add pthread_detach_pwd call.

[Rich Felker]

On Mon, Oct 21, 2013 at 02:54:00PM +0200, Florian Weimer wrote:
> On 10/21/2013 02:42 PM, Joseph S. Myers wrote:
> >On Mon, 21 Oct 2013, Florian Weimer wrote:
> >
> >>>Feel free to propose/implement new *at functions for glibc.  That doesn't
> >>>depend on kernel support (although kernel support would be good) because
> >>>you can implement them in userspace using /proc/self/fd, just like many
> >>>existing fallback implementations for !__ASSUME_ATFCTS.
> >>
> >>Interesting.  Is constructing such names
> >>
> >>       static const char procfd[] = "/proc/self/fd/%d/%s";
> >>
> >>race-free?  I'm asking because the /proc/self/fd entries are presented as
> >>symbolic links.
> >
> >I don't see why this technique would involve any races different from a
> >direct syscall.  In both cases, if another thread changes the file
> >descriptor at the same time as the call, you can't predict whether the old
> >or new version would be used.
> 
> I was wondering if the kernel performs symlink resolution behind the
> scenes, or if it uses the file descriptor directly.  But based on a
> quick experiment, it should be race-free.  This looks rather nice.

The symlinks in /proc/$pid/fd/ are not symlinks; getdents and readlink
just falsely present them as such. They're magic entries that attach
directly to the open file description. For O_PATH file descriptors,
they're attached permanently to the inode resolved by the original
call to open.

Rich