Re: Thread-, Signal- and Cancellation-safety documentation

[Florian Weimer <fweimer at redhat dot com>]

On 04/08/2013 06:28 PM, Rich Felker wrote:
> On Mon, Apr 08, 2013 at 11:10:25AM +0200, Florian Weimer wrote:
> > On 03/26/2013 07:43 AM, Rich Felker wrote:
> > > I know your work is just documenting existing practice, but unless
> > > there's a clause in POSIX (and now, C11 too, since C11 has threads)
> > > which allows this, I think the underlying issue should be fixed. The
> > > cleanest fix I can envision would be atomically replacing the pointer
> > > to the locale object once the new one is prepared. This would
> > > eliminate the need for readers to lock anything.
> >
> > So we don't deallocate locale data, ever?  Then this might work.
>
> I don't see a clean way to deallocate it without making things slow.

If isspace and friends could be turned into function calls and really 
expensive deallocation is acceptable, we could temporarily map a page 
with a different implementation (with safepoint logic), halt all the 
other threads, check if their %rip points into the magic page, restart 
those threads and wait until they signal that they have reached a 
safepoint, perform the deallocation, release the locks.

It's probably not worth the effort for LC_CTYPE, though, and there's 
still a performance hit because of the loss if inlining.

--
Florian Weimer / Red Hat Product Security Team