[Bug libc/21793] glibc does not update the pid/tid cache after clone()

[carlos at redhat dot com]

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

--- Comment #8 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #3)
> (In reply to Carlos O'Donell from comment #2)
> > Once you call clone() you own the created thread, and you cannot use any
> > POSIX Thread functions provided by the libc you left behind when you cloned
> > a new thread manually. If you are using clone() as a convenience function
> > for unshare() then you should use unshare().
> 
> That is very misleading.  If you call clone to create a new *thread*, you
> cannot use any glibc function at all, whether POSIX threads or not. 
> *Nothing* will work on the new thread, not even async-signal-safe functions.
> A lot of things worked by accident, most of the time, including malloc, but
> with the thread cache in 2.26, malloc will no longer be reliable, for
> instance.

You are absolutely right, I didn't mean to limit the scope to just the POSIX
thread functions, but was answering in the context of this issue and that made
my response misleading.

> We still need a correct TID if the clone call created a new process, though.
> There is really no way around that.  This will be tricky due to vfork.

When you say 'we' do you mean just glibc internally? If so, then I agree. The
library needs a correct TID in order for it's own functions to work reliably,
the user doesn't need a TID and we don't provide gettid() nor document what a
TID is in respect to a PID or pthread_t.

I think what's under contention here is: Should clone() with the appropriate
flags to behave like fork(), or vfork(), actually be a supported API which
after calling still allows you to call back into the runtime?

Are you arguing that when clone() is used in a fork-like manner that it should
work just like fork. Why not just use fork() or vfork()?

I agree with Adhemerval that the use of clone() is bound to cause us no end of
problems, and that we should document that after a clone() call you can't call
any libc functions. You have effectively ended the ability to use any library
functions until you execve, much like the official story for vfork().

If anything we should be adding documentation to state which functions are, as
a GNU extension, supported and safe to call between vfork() and exec()/exit().
Which would be easier to explain and document those semantics.

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