[cfe-dev] libc++ mutex destructor assertion

[Nico Weber]

On Fri, Jun 13, 2014 at 12:57 PM, Zachary Turner <zturner at google.com> wrote:

> 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
>

http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions


> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/73db966c/attachment.html>