[Bug nptl/17214] Expose a function to reset the PID cache

["jld at mozilla dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17214

Jed Davis <jld at mozilla dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jld at mozilla dot com

--- Comment #10 from Jed Davis <jld at mozilla dot com> ---
(In reply to Ricky Zhou from comment #9)
> We cannot unshare(CLONE_NEWPID); fork(); for each new process because Linux
> does not support calling unshare(CLONE_NEWPID) multiple times. As Steven
> said, I think either of the following would solve our problems:
> 
>  - Expose a way to invalidate glibc's PID cache
>  - Allow child_stack to be NULL (leading to fork-like behavior) when
> CLONE_VM is not set.

Another alternative: expose a variant of fork() which can be passed additional
flags to pass to clone; __fork_with_flags(0) would be equivalent to fork(), and
it could fail with EINVAL if inappropriate bits are set (CLONE_VM, any of the
tid set/clear flags, anything in the signal number field).  There may be a
better name than __fork_with_flags, but hopefully the idea is clear enough.

The advantage over __clone with no child_stack is that it would run
pthread_atfork handlers; this would allow taking advantage of, for example,
malloc implementations that use pthread_atfork to allow allocation on the child
side of a multithreaded fork.

Gecko is more or less able to work around this without too much effort because
the child process creation already had to be refactored to work in the absence
of pthread_atfork (https://bugzilla.mozilla.org/show_bug.cgi?id=772734#c15),
but it would be nice to have the possibility of eventually getting away from
that requirement.

-- 
You are receiving this mail because:
You are on the CC list for the bug.