| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
The code example in log-walker.c was wrong as get_valid_accounts() is
(transfer container). dup_valid_accounts() is (transfer full) so it's correct
now.
https://bugs.freedesktop.org/show_bug.cgi?id=69797
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Earlier we were using threads to implement the asynchronous get_events
and rewind methods, so we used a mutex to serialize them. However, now
get_events has been moved to a single threaded model, so using a mutex
will lead to undefined behaviour.
Instead we use a queue to store incoming operations (ie. get_events or
rewind) and they are executed one after the other.
Fixes: https://bugs.freedesktop.org/54270
|
|
|
|
|
|
| |
As a result we don't need the wrapper callback for fill_cache.
Fixes: https://bugs.freedesktop.org/54270
|
|
|
|
| |
Fixes: https://bugs.freedesktop.org/54270
|
|
|
|
| |
Fixes: https://bugs.freedesktop.org/54270
|
|
|
|
| |
Purely cosmetic. No changes in functionality.
|
|
|
|
|
|
|
|
|
|
| |
This ensures that the TplLogEventFilter is always run from the same
thread which invoked the walker. This is implemented by keeping track
of skipped events in the history instead of silently ignoring them
within the LogIters. This has the nice side effect that we do not need
to run the filter while rewinding.
Fixes: https://bugs.freedesktop.org/54270
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... so that only the caches are filled asynchronously and the rest of
the work does not involve the use of a separate thread. This is the
first step towards ensuring that we do not run the TplLogEventFilter
from a separate thread.
NB: This does not solve the actual problem. The TplLogEventFilter is
still invoked from a separate thread. However this refactoring lets us
move in that direction.
Fixes: https://bugs.freedesktop.org/54270
|
| |
|
|
|
|
| |
Fixes: https://bugs.freedesktop.org/41772
|
| |
|
|
|
|
| |
Fixes: https://bugs.freedesktop.org/41772
|
|
|
|
| |
Fixes: https://bugs.freedesktop.org/41772
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This represents the order in which events were handed over to the user
from each iterator. Lets say we have 10 events numbered from 0 to 9,
with 0 being the oldest and 9 the latest event, and we have 3
iterators Ia, Ib and Ic. If they were returned in batches of 5 as:
+-----+--------+
|event|iterator|
+-----+--------+
| 5 | Ia |
| 6 | Ib |
| 7 | Ia |
| 8 | Ia |
| 9 | Ic |
+ - - + - -- - +
| 0 | Ic |
| 1 | Ic |
| 2 | Ib |
| 3 | Ib |
| 4 | Ia |
+-----+--------+
Then the list would be:
(Ic, 2), (Ib, 2), (Ia, 2), (Ib, 1), (Ia, 2), (Ic, 1)
Fixes: https://bugs.freedesktop.org/41772
|
|
|
|
|
|
|
| |
Since the TplLogWalker API is asynchronous, we do not want multiple
overlapping calls to stamp on each others' toes.
Fixes: https://bugs.freedesktop.org/41772
|
|
|
|
| |
Fixes: https://bugs.freedesktop.org/41772
|
|
|
|
| |
Fixes: https://bugs.freedesktop.org/41772
|
|
|
|
| |
Fixes: https://bugs.freedesktop.org/41772
|
|
Fixes: https://bugs.freedesktop.org/41772
|