Only a weaker sense of priorities is implemented, alluding to distinct set of pros and cons compared to the stronger, strict approach to them as widely applied in this problem space (since the latter gives the application more control as the effect of the former can still be achieved with some reductions, whereas it is not straightforward the other way around; cf. static priority task scheduling vs. relative fine-tuning within a single priority domain with nice(2)):
implicit mitigation for deadlock-prone priority arrangements
less predictable (proportional probability based, we can talk about an advisory effect of the priorities) responses to the arrival of the high-ranked events (i.e. in the process of the picking the next event to handle from the priority queue when at least two different priorities are eligible at the moment)
One practical application for this module of libqb is in combination with IPC servers based on qbipcs.h published one (the qb_ipcs_poll_handlers structure maps fittingly to the control functions published here).
qb_loop_job_del(3), qb_loop_run(3), qb_loop_create(3), qb_loop_stop(3), qb_loop_poll_low_fds_event_set(3), qb_loop_signal_del(3), qb_loop_signal_add(3), qb_loop_job_add(3), qb_loop_poll_del(3), qb_loop_destroy(3), qb_loop_timer_expire_time_remaining(3), qb_loop_poll_mod(3), qb_loop_signal_mod(3), qb_loop_timer_del(3), qb_loop_timer_add(3), qb_loop_timer_is_running(3), qb_loop_timer_expire_time_get(3), qb_loop_poll_add(3)
Copyright (C) 2010-2020 Red Hat, Inc.