This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Thread-, Signal- and Cancellation-safety documentation
- From: Rich Felker <dalias at aerifal dot cx>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 9 Apr 2013 09:51:31 -0400
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <orppym7okv dot fsf at livre dot home> <20130326064347 dot GL20323 at brightrain dot aerifal dot cx> <51628981 dot 8030406 at redhat dot com> <20130408162859 dot GQ20323 at brightrain dot aerifal dot cx> <5163D969 dot 1080701 at redhat dot com>
On Tue, Apr 09, 2013 at 11:03:37AM +0200, Florian Weimer wrote:
> 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.
Indeed, I thought of this exact same approach, but didn't mention it
because I deemed it both expensive (in runtime cost) and indefensibly
hideously ugly. :-)
Rich