Don't abort() on locking assertions if LIBXCB_ALLOW_SLOPPY_LOCK is set.
authorJamey Sharp <jamey@minilop.net>
Tue, 23 Oct 2007 18:03:33 +0000 (11:03 -0700)
committerJamey Sharp <jamey@minilop.net>
Tue, 23 Oct 2007 18:44:20 +0000 (11:44 -0700)
But do still print a full backtrace, on platforms where that's
supported.

This commit follows the spirit of Novell's libxcb-sloppy-lock.diff.

I strongly opposed proposals like this one for a long time. Originally I
had a very good reason: libX11, when compiled to use XCB, would crash
soon after a locking correctness violation, so it was better to have an
informative assert failure than a mystifying crash soon after.

It took some time for me to realize that I'd changed the libX11
implementation (for unrelated reasons) so that it could survive most
invalid locking situations, as long as it wasn't actually being used
from multiple threads concurrently.

The other thing that has changed is that most of the code with incorrect
locking has now been fixed. The value of the assert is accordingly
lower.

However, remaining broken callers do need to be fixed. That's why libXCB
will still noisily print a stacktrace (if possible) on each assertion
failure, even when assert isn't actually invoked to abort() the program;
and that's why aborting is still default. This environment variable is
provided only for use as a temporary workaround for broken applications.

Signed-off-by: Jamey Sharp <jamey@minilop.net>
Acked-by: Josh Triplett <josh@freedesktop.org>

No differences found