]> git.ipfire.org Git - thirdparty/haproxy.git/commit
DEBUG: threads: merge successive idempotent lock operations in history
authorWilly Tarreau <w@1wt.eu>
Mon, 5 May 2025 16:24:40 +0000 (18:24 +0200)
committerWilly Tarreau <w@1wt.eu>
Mon, 5 May 2025 16:36:12 +0000 (18:36 +0200)
commitfeaac66b5e2dda4ffc0ab97ac3f3ecacf8aa86c2
tree32a62e542d8bbc1b5d1126ce8380ff1a8fb04773
parent743dce95d28c885bf0f7eca34583014bbb7aebf1
DEBUG: threads: merge successive idempotent lock operations in history

In order to make the lock history a bit more useful, let's try to merge
adjacent lock/unlock sequences that don't change anything for other
threads. For this we can replace the last unlock with the new operation
on the same label, and even just not store it if it was the same as the
one before the unlock, since in the end it's the same as if the unlock
had not been done.

Now loops that used to be filled with "R:LISTENER U:LISTENER" show more
useful info such as:

  S:IDLE_CONNS U:IDLE_CONNS S:PEER U:PEER S:IDLE_CONNS U:IDLE_CONNS R:LISTENER U:LISTENER
  U:STK_TABLE W:STK_SESS U:STK_SESS R:STK_TABLE U:STK_TABLE W:STK_SESS U:STK_SESS R:STK_TABLE
  R:STK_TABLE U:STK_TABLE W:STK_SESS U:STK_SESS W:STK_TABLE_UPDT U:STK_TABLE_UPDT S:PEER

It's worth noting that it can sometimes induce confusion when recursive
locks of the same label are used (a few exist on peers or stick-tables),
as in such a case the two operations would be needed. However these ones
are already undebuggable, so instead they will just have to be renamed
to make sure they use a distinct label.
include/haproxy/thread.h