This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Caching of PID/TID after fork
* Robert Święcki:
>> The other question I have is whether we talk about clone-as-fork
>> exclusively. Introducing a new thread into the process on which
>> non-free-standing code can run using clone is a different matter
>> altogether.
>
> To my knowledge, in the vast majority of cases (or even, in all
> cases), where the TID/PID caching problem surfaced, it could have been
> solved by fork_with_flags() indeed.
So no new thread? Good.
> Though, one useful feature which could be potentially useful for some
> porjects would be to create a detached process (for which the kernel
> doesn't send termination signal - usually SIGCHLD - to the parent
> process). And this cannot be solved by ORing custom flags with fork
> ones, because SIGCHLD is already there. But, it's just a guess.
Yes, I know of some cases where this would have helped as well.
If we go the fork-with-flags route, we should translate glibc-specific
flags to kernel flags anyway because the kernel might introduce new
flags which break the interface in subtle ways (see O_TMPFILE and mode
argument handling).