[cfe-dev] libc++ mutex destructor assertion

[Chandler Carruth]

On Fri, Jun 13, 2014 at 8:47 PM, Rui Ueyama <ruiu at google.com> wrote:

> On Fri, Jun 13, 2014 at 11:21 AM, Zachary Turner <zturner at google.com>
> wrote:
>
>> I guess ultimately if it's undefined behavior, then we just to make sure
>> we don't call exit() under a lock_guard, and perhaps it's better for the
>> library to fail violently rather than gracefully so that we're alerted of
>> the problems sooner.  So no change to libc++ necessary (if anything, maybe
>> make the mutexes assert more consistently.  Currently only recursive_mutex
>> asserts, and the others don't).
>>
>
> Requesting not to call a function that could call exit() from the code
> within lock_guard is too much burden for developers. It'd be similar to a
> signal handler from which you can call only very limited set of functions.
> If you call a function F from code within lock_guard, you'd need to
> guarantee for the future that nobody will never add exit() to F or any
> function that could indirectly be called from F. I imagine that's too hard
> to guarantee.
>

I don't think this is that bad.

So, first, the condition is narrower: you can't be holding a lock on a
*global* mutex whose destructor would consequentially be run upon the call
to exit. If you have a local mutex or any other non-global mutex, you're
fine.

Second, under what circumstances is it reasonable for *any* library
function to call exit? Pretty few IMO. If that is a possibility, I think
you (to an extent) already need to be very aware of that.

Let's consider having an open file object with a guard around it which will
flush the contents written to the file to disk. If you call any function
which could call exit, you may lose data. There are a lot of other
analogous circumstances where programmers must already operate with this
caution in mind, and most of them seem *more* concerning than the mutex
case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140613/321054dc/attachment.html>