This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]