On Sat, Nov 25, 2017 at 01:26:18AM -0800, Hal Murray via devel wrote:
> (gdb) bt
> #0 0x76ebf104 in futex_wake (private=0, processes_to_wake=2147483647,
> futex_word=0x76eaf618) at ../sysdeps/unix/sysv/linux/futex-internal.h:231
> #1 __pthread_once_slow (once_control=0x76eaf618, init_routine
On Sat, Nov 25, 2017 at 05:09:02AM -0800, Hal Murray wrote:
>
> k...@roeckx.be said:
> > This means that when we initialize a global variable we use the
> > pthread_once() function, which internally uses the futex to do that. It's
> > not using threads itself, it's just making sure that if you use
k...@roeckx.be said:
> This means that when we initialize a global variable we use the
> pthread_once() function, which internally uses the futex to do that. It's
> not using threads itself, it's just making sure that if you use threads
> things work properly.
Thanks.
Do we have to link with pt
An interesting tangle. I'm cleaning up odds and ends, including upgrading
Raspberry Pi-s to Stretch. One of them dies with a SIGSYS trap.
It's dieing on 240 which is futex. That's locks, only needed if you are
using threads. This system was built with --disable_dns_lookup, so there
shouldn'
