<div dir="ltr">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.<div><br></div><div>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.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 13, 2014 at 12:47 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Fri, Jun 13, 2014 at 11:21 AM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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).</div>
</blockquote><div><br></div></div><div>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.</div>
<div class="">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 13, 2014 at 11:05 AM, Howard Hinnant <span dir="ltr"><<a href="mailto:howard.hinnant@gmail.com" target="_blank">howard.hinnant@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Jun 13, 2014, at 1:34 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>
<br>
><br>
> On Fri, Jun 13, 2014 at 6:32 PM, David Majnemer <<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>> wrote:<br>
>> 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.<br>
>><br>
>><br>
>>> It's very easy to support this -- just don't call pthread_mutex_destroy(), the function has no purpose really.<br>
>>><br>
>> 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.<br>
>><br>
> 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.<br>
<br>
</div></div>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.<br>
<br>
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.<br>
<span><font color="#888888"><br>
Howard<br>
</font></span><div><div><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div></div><br></div></div>
</blockquote></div><br></div>