Re: Caching of PID/TID after fork

[Robert Święcki <robert at swiecki dot net>]

> Also, providing a glibc own symbol to update the tid/pid is messy:
> it would be an internal implementation detail which in theory
> application should not have access to, it might add some
> synchronization issues (what happens if you try to force update
> after a mutex operation with default wrong value?), and it also
> might be tricky to add a compatibility symbol in case of change
> how tid/pid internally works.

Thanks, this is good analysis.

> Another possibility is to use another thread unique identifier
> as the owner instead of tid (maybe a hash of pthread_t
> to fit on a int).  By removing this requirement I think it is
> feasible to get rid of caching.

Another dev told me that chromium developers implemented ForkWithFlags
- https://codereview.chromium.org/800183004/ - to deal exactly with
the problem is caching PID/TID. They used the setjmp/longjmp approach
suggested by Rich.

My point is that a lot of projects which use the clone syscall will be
hit by this problem, and getting to (or finding in glibc mail
archives) the working solution might take a lot of time. It's because
of the rise of namespaces, more and more projects will be using the
syscall for various forms of containerization.

Maybe providing something like fork_with_flags(int flags) would work
here? Seems that most (all?) the projects that I've seen, which use
clone() directly and had problems with caching of TID/PID, basically
need fork with some flags (mainly of the CLONE_NEW* type). Such
function would deal with tid/gid/locks/pthread_atfork as fork does,
but would also OR the provided flags with the canonical ones?

-- 
Robert Święcki