Proxmox-Port/libqb
1
0
Fork 0
mirror of https://salsa.debian.org/ha-team/libqb synced 2026-08-10 07:35:34 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
1,349 Commits 8 Branches 125 Tags 5.3 MiB
C 48.8%
Shell 26.5%
Makefile 20.4%
M4 4.1%
Roff 0.2%
97adfa6ba0
Go to file
Jan Pokorný 97adfa6ba0
IPC: server: avoid temporary channel priority loss, up to deadlock-worth 
It turns out that while 7f56f58 allowed for less blocking (thus
throughput increasing) initial handling of connections from clients
within the abstract (out-of-libqb managed) event loop, it unfortunately
subscribes itself back to such polling mechanism for UNIX-socket-check
with a default priority, which can be lower than desired (via explicit
qb_ipcs_request_rate_limit() configuration) for particular channel
(amongst attention-competing siblings in the pool, the term here
refers to associated communication, that is, both server and
on-server abstraction for particular clients).  And priority-based
discrepancies are not forgiven in true priority abiding systems
(that is, unlikele with libqb's native event loop harness as detailed
in the previous commit, for which this would be soft-torelated hence
the problem would not be spotted in the first place -- but that's
expliicitly excluded from further discussion).

On top of that, it violates the natural assumption that once (single
threaded, which is imposed by libqb, at least between initial accept()
and after-said-UNIX-socket-check) server accepts the connection, it
shall rather take care of serving it (at least within stated initial
scope of client connection life cycle) rather than be rushing to accept
new ones -- which is exactly what used to happen previously once the
library user set the effectively priority in the abstract poll
above the default one.

It's conceivable, just as with the former case of attention-competing
siblings with higher priority whereby they could _infinitely_ live on
at the expense of starving the client in the initial handling phase
(authentication) despite the library user's as-high-as-siblings
intention (for using the default priority for that unconditionally
instead, which we address here), the dead lock is imminent also in
this latter accept-to-client-authentication-handling case as well
if there's an _unlimited_ fast-paced arrival queue (well, limited
by with number of allowable open descriptors within the system,
but for the Linux built-in maximum of 1M, there may be no practical
difference, at least for time-sensitive applications).

The only hope then is that such dead-locks are rather theoretical,
since a "spontaneous" constant stream of either communication on
unrelated, higher-prio sibling channels, or of new connection arrivals
can as well testify the poor design of the libqb's IPC application.
That being said, unconditional default priority in the isolated
context of initial server-side client authentication is clearly
a bug, but such application shall apply appropriate rate-limiting
measures (exactly on priority basis) to handle unexpected flux
nonetheless.

The fix makes test_ipc_dispatch_*_glib_prio_deadlock_provoke tests pass.

Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
2019-06-05 10:36:55 +02:00
.tito build: tito: unify custom.py with pacemaker's version 2016-12-16 15:48:25 +01:00
build-aux UPDATED: doc (ABI comparison) and various other fixes (#324) 2018-09-25 08:38:37 +01:00
docs Fix comment typo (#296) 2018-03-20 13:12:06 +00:00
examples Add the option of hi-res (millisecond) timestamps (#329) 2018-11-09 09:56:44 +00:00
include doc: qbarray.h: remove stray asterisk and parentheses 2019-05-07 14:46:02 +01:00
lib IPC: server: avoid temporary channel priority loss, up to deadlock-worth 2019-06-05 10:36:55 +02:00
m4 tests: use RUNPATH instead of RPATH consistently (#309) 2018-05-03 16:03:54 +01:00
tests tests: ipc: check deadlock-like situation due to mixing priorities 2019-06-04 13:07:27 +02:00
tools doc: qblog.h: syslog rarely appropriate for ordinary programs 2017-12-14 10:42:09 +01:00
.gitattributes build: allow for being consumed in a (non-endorsed) form of snapshots 2018-09-13 10:54:16 +02:00
.gitignore build: allow for being consumed in a (non-endorsed) form of snapshots 2018-09-13 10:54:16 +02:00
.tito.spec.tmpl build: allow for git -> automatic COPR builds integration 2016-11-18 23:32:44 +01:00
.travis.yml log: Remove more dead code from linker callsites (#331) 2018-11-12 15:55:33 +00:00
autogen.sh build: allow for being consumed in a (non-endorsed) form of snapshots 2018-09-13 10:54:16 +02:00
check UPDATED: doc (ABI comparison) and various other fixes (#324) 2018-09-25 08:38:37 +01:00
coding_style.txt Point the link to the Linux kernel coding style document to the right place (#256) 2017-05-26 14:15:32 +01:00
configure.ac [tests] allow installation of test suite 2019-03-26 11:31:05 +00:00
COPYING Re-license to LGPL 2.1 2010-05-25 06:11:59 +10:00
INSTALL The license is in COPYING, not LICENSE 2015-12-16 19:28:20 +01:00
libqb.spec.in [tests] enable building / shipping of libqb-tests.rpm 2019-03-26 11:31:05 +00:00
Lindent Change Lindent options to break the procedure type. 2011-06-22 14:19:14 +10:00
Makefile.am [tests] export SOCKETDIR from tests/Makefile.am 2019-03-26 11:31:05 +00:00
README.markdown doc: README: add a status badge+link for the COPR builds 2016-11-22 16:36:26 +01:00

README.markdown

libqb

What is libqb?

libqb is a library with the primary purpose of providing high-performance, reusable features for client-server architecture, such as logging, tracing, inter-process communication (IPC), and polling.

libqb is not intended to be an all-encompassing library, but instead provide focused APIs that are highly tuned for maximum performance for client-server applications.

Build Status COPR Build Status

For more information, see:

Dependencies

  • glib-2.0-devel (If you want to build the glib example code)
  • check-devel (If you want to run the tests)
  • doxygen and graphviz (If you want to build the doxygen man pages or html manual)

Source Control (GIT)

git clone git://github.com/ClusterLabs/libqb.git

See Github

Installing from source

$ ./autogen.sh
$ ./configure
$ make
$ sudo make install

How you can help

If you find this project useful, you may want to consider supporting its future development. There are a number of ways to support the project.