This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Testing glibc 2.24 on remaining machines.
- From: David Miller <davem at davemloft dot net>
- To: triegel at redhat dot com
- Cc: carlos at redhat dot com, libc-alpha at sourceware dot org, rth at redhat dot com, samuel dot thibault at ens-lyon dot org, hjl dot tools at gmail dot com, vapier at gentoo dot org, schwab at suse dot de, chunglin_tang at mentor dot com, adhemerval dot zanella at linaro dot org
- Date: Thu, 21 Jul 2016 09:25:17 -0700 (PDT)
- Subject: Re: Testing glibc 2.24 on remaining machines.
- Authentication-results: sourceware.org; auth=none
- References: <521d3f7a-6375-11c7-5987-ad2f0f1ab290@redhat.com> <20160720.153931.575029361394679476.davem@davemloft.net> <1469100768.13664.13.camel@localhost.localdomain>
From: Torvald Riegel <triegel@redhat.com>
Date: Thu, 21 Jul 2016 13:32:48 +0200
> (3) build something that emulates full C11 atomics, either backed by
> locks in the synchronization data structure or a process-global lock
> array (though we'd have to adapt the current condvar because there's no
> space for an extra lock there)?
Nothing done completely inside of glibc will support signals properly.
Even the current locking in glibc deadlocks in several testcases
because of this problem.
Like some other architectures in the same situation have done, we
would need something in the kernel to implement locking properly
and in a signal safe way.
And it's really hard to justify all of that work.