Re: Caching of PID/TID after fork

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 07/10/2016 11:44, Robert Święcki wrote:
> 2016-10-07 2:43 GMT+02:00 Zack Weinberg <zackw@panix.com>:
> 
>>> I've thought for quite some time that there should be a second
>>> clone-wrapper in glibc that doesn't ask for a new stack.  It might be
>>> better to call it something with "clone" in the name, but I don't care
>>> terribly much.
>>
>> Meant to say: in addition to the PID/TID caching issues, this would be
>> able to run pthread_atfork() handlers.
> 
> Maybe..
> 
>  __clone3(unsigned long clone_flags, void* newsp, pid_t*
> parent_tidptr, pid_t* child_tidptr, void* tls);
> 
> ?
> 
> __clone2 seems to be used with ia64 already.
> 

The problem about this approach for clone it is current platform
specific, meaning it requires an assembly crafted routine for each
port.  Adding another one will require additional burden of making
current clone implementation either generic to provide clone and
clone3 or adding another clone3 implementation for *each* port.
And it would also add more additional effort for new ports.

I still think a better approach would be to just focus on try
remove the caching altogether without introducing performance
regressions.