[cfe-dev] libc++ mutex destructor assertion

[Zachary Turner]

FWIW I agree with you that it's an unreasonable burden, but if it's UB then
we can't guarantee anything about what other implementations of libc++
might do.

That being said, as a general principle I think that a library should never
call exit().  But admittedly it's kind of deeply engrained into LLVM, and
difficult to fix it the right way.  I guess if we could use C++ exceptions
in LLVM it would become a little easier, as all calls to exit could be
replaced with a throw that's caught at the top-level, and then we could
just ban exit() in the style guide.


On Fri, Jun 13, 2014 at 12: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.
>
>
>> On Fri, Jun 13, 2014 at 11:05 AM, Howard Hinnant <
>> howard.hinnant at gmail.com> wrote:
>>
>>> On Jun 13, 2014, at 1:34 PM, Chandler Carruth <chandlerc at google.com>
>>> wrote:
>>>
>>> >
>>> > On Fri, Jun 13, 2014 at 6:32 PM, David Majnemer <
>>> david.majnemer at gmail.com> wrote:
>>> >> It is very reasonable for this to be UB.  Imagine a mutex where
>>> memory is allocated in pthread_mutex_init and free'd in
>>> pthread_mutex_destroy.  Unlocks which race with the destruction may end up
>>> partying on free'd memory.
>>> >>
>>> >>
>>> >>> It's very easy to support this -- just don't call
>>> pthread_mutex_destroy(), the function has no purpose really.
>>> >>>
>>> >> This is not true. Some implementations, like FreeBSD's libthr, free
>>> memory in their pthread_mutex_destroy.  Not calling pthread_mutex_destroy
>>> will lead to leaks.
>>> >>
>>> > This ... makes me extremely sad. It makes mutexes significantly more
>>> annoying to use in a bunch of patterns if you cannot destroy them while
>>> locked.
>>>
>>> Fwiw, I once wrote a mutex adaptor/wrapper where in its destructor it
>>> locked itself, and then did the necessary de-initialization, then put
>>> itself in a “destructed state” and unlocked itself.  When another thread
>>> comes along and tries to lock it after destruction, it recognizes the
>>> destructed state and throws an exception.  Not 100% bulletproof.  But when
>>> the mutex has static storage duration, can be fairly effective.
>>>
>>> That being said, this particular wrapper would not be useful in
>>> Zachary’s example as the lock is leaked by the exiting thread.  However one
>>> can dream up all kinds of variations on custom mutexes, and they can all
>>> interoperate with std::lock_guard, std::unique_lock,
>>> std::condition_variable_any, std::lock, etc.
>>>
>>> Howard
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140613/dcf5ab6e/attachment.html>