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)
commit4d828c5eba9fc7161c5f18650f2dbe218e1db06f
tree5b171f1c6d59930e77fa91bb05608104d6ae9d85
parent09045eaac34973662aaa820a94ca8ed66d9dcb4e
Don't abort() on locking assertions if LIBXCB_ALLOW_SLOPPY_LOCK is set.

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>
src/xcb_conn.c
src/xcb_xlib.c
src/xcbint.h