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

[Rich Felker <dalias at aerifal dot cx>]

On Thu, Apr 04, 2013 at 04:04:52PM -0300, Alexandre Oliva wrote:
> > The cleanest fix I can envision would be atomically replacing the
> > pointer to the locale object once the new one is prepared.
> 
> If it was a single pointer, that would indeed be a good course of
> action, but there are multiple pointers that may each change
> independently *or* with a single setlocale call.  Plus, we modify a
> global object, which gets implicitly passed to some functions which read
> from it often without expecting that it might change.

My naive guess is that the optimal solution is for setlocale to grab a
write lock only when changing multiple categories, and also make each
individual change with an atomic pointer swap.

This way, functions which only depend on one category can operate with
no locking, and only functions that need two or more categories need
to obtain a read lock.

> >> therefore well-defined and safe.  In the end, fclose turned out to be
> >> AS-Unsafe for other reasons (a non-recursive gconv mutex that could
> >> self-deadlock), but the rationale, if agreed by the community as sound,
> >> may be reused in other settings.
> 
> > Doesn't the freeing make it unsafe?
> 
> Why would it?  (given that calling any other stream function, including

Because free() is AS-Unsafe.

> > It's basically impossible to be AC safe without simply disabling async
> > cancellation before doing your work then reenabling it afterwards.
> 
> I don't quite agree with that; I don't see that it would be impossible
> for a suitable cleanup region to start right after the atomic operation
> that sets a lock, for example, but I don't see that we have means to
> express that in C with a sufficiently level of detail to guarantee
> unambiguous safety.

That's definitely not expressable in C. BTW this issue is connected to
bug #12683, which still remains unacknowledged: cancellation points
are implemented in terms of temporarily enabling async cancellation,
but the cleanup region does not end atomically with the side effects
of the syscall.

Rich