[cfe-dev] libc++ mutex destructor assertion

[Zachary Turner]

Oh, yea I'm aware of the rule.  I'm not suggesting LLVM should allow them,
it was just a passing comment about how it might be fixed in a better/safer
manner in a hypothetical world where exceptions were allowed.


On Fri, Jun 13, 2014 at 1:40 PM, Nico Weber <thakis at chromium.org> wrote:

> 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/2b065311/attachment.html>