[Bug libc/29585] sched_getcpu returns invalid results

["mjbaars1977 at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #11 from Mischa Baars <mjbaars1977 at gmail dot com> ---
(In reply to Florian Weimer from comment #9)
> (In reply to Mischa Baars from comment #8)
> > (In reply to Florian Weimer from comment #7)
> > > You cannot call glibc function after creating a bare thread using clone, you
> > > need to use direct system calls. The bare thread does not have a proper
> > > thread control block set up for glibc.
> > 
> > Ok, no problem. I can use syscalls to retrieve the processor the process is
> > running on, but shouldn't glibc check for the existence of this thread
> > control block and return a -1 when it does not exist instead of a incorrect
> > processor number?
> 
> There is no efficient way to check if the TCB is safe to use from the
> current thread.
> 
> > I think that a small note in the manual page about pthreads vs fork / clone
> > would be in order. For example, if the existence of both pthread_yield and
> > sched_yield makes you think that sched_yield is not specifically intended
> > for use with pthreads, then why would sched_getcpu be?
> 
> sched_getcpu is not related to pthreads any more than the rest of glibc.

Hi Florian,

A little more detail of what we're dealing with here:

I can't tell if this this is in any way related to a thread control block, but
without the CLONE_VM option passed to clone(), sched_getcpu() is working fine,
with the CLONE_VM option passed to clone(), it isn't.

Just in case you were still interested :)

Best regards,
Mischa Baars.

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