A timer in QB_POLL_ENTRY_JOBLIST doesn't necessarily
have a t->timerlist_handle so that deref can segv. Also
the comment assumes the timers are threaded - which as we have
decided is definitely not true. So it's safe to move the check
earlier.
In the tests, I've adjusted the timeouts so that they definitely
happen at different times. On some architectures they can fire
concurrently and in the wrong order.
* tlist: Add heap based implementation of timer list
Previous timer was sorted list implementation of priority queue
and very slow when number of timers increased. This is mostly
not a problem because usually only few timers are used.
But for application where bigger number of timers are needed
it may become problem.
Solution is to use binary heap based priority queue which is much
faster.
API is unchanged, just timerlist_destroy is added which should be called
to free heap array. This function also destroys mutex (omitted when
mutex was added).
* tests: Fix check loop mt test
test_th was accesed both by main thread and loop_timer thread resulting in
failure. Fix is to access test_tht in loop_timer thread.
Speed test is adding only 10000 items so it is reasonable
fast even with sorted linked list implementation.
Signed-off-by: Jan Friesse <jfriesse@redhat.com>
In case of hdb.c, the problem is that `check` public API (qb_hdb_handle
member struct) item (which should not be exposed publicly like this
in the first place!) is typed as `int32_t`, whereas it was to be
compared to `uint32_t` implementation-possessed local variables
(presumably derived from the same source), which made the compiler
upset (even though there was no real reason, integer promotion to
unsigned type would happily occur, which is furthermore expected to
be fully defined as these values come from `random` that shall
return non-negative integers below `INT32_MAX`).
Hence:
- type these local variables to `int32_t` just as well, which allows to
- simplify `random` return value handling, since they are expected to be
zero-or-greater and the previously extra tested all-bits-on pattern
makes undoubtfully for a negative numeric value in case of a signed
integer with specified width (c.f. 7.18.1.1/C99), hence falling into
complement of zero-or-greater; zero itself is also excluded for the
reasons stated in the comment (which was pretty hazy and incorrect,
so it gets overhaul as well)
- also superfluous typecasts are removed
Similar situation is with loop_timerlist.c, where we are actually fully
in charge of the struct member (private API), but there are good reasons
to stay consistent with the former file as the same applies to the
source of that value -- it comes from `random` (equivalent comment
is added here for greater symmetry).
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
timefd is using too much cpu and it is using up
file descriptors.
timelist is also more portable and now I have less
code to maintain.
Signed-off-by: Angus Salkeld <asalkeld@redhat.com>
This changes the timer hande from a live pointer to a handle
more like hdb handles (minus the ref counting).
What i like about this is it is not neccessary to clear
the applications handle using memset().
Signed-off-by: Angus Salkeld <asalkeld@redhat.com>
