https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2007-03-03 13:31:17 |2015-8-26
CC| |fxcoudert at gcc dot gnu.org
--- Comment #41 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #39)
> Anything can happen when you invoke undefined behavior.
Yes. Yet, as a "quality of implementation" issue, it is desirable for us to
detect and error out on recursive I/O. Simply as indicated by the number of
duplicates of this bug, it's a common occurrence (currently on Darwin, but I
think there is no guarantee that the deadlocks don't start manifesting
themselves anytime on another platform).
The question is: can we do it with the current lock implementation? Do we have
a way to check, when we want to acquire that lock (get_external_unit), in the
case where the lock is already held, whether it's by the same thread or not.
I.e., prevent the deadlock.
I don't know how the gthread API works, but POSIX threads allow that if I read
correctly: using a PTHREAD_MUTEX_ERRORCHECK-type mutex and check for EDEADLK on
pthread_mutex_lock(). Jakub, does this sound possible the way I propose it?
