6ea2aecb |
1 | Linux Trace Toolkit |
2 | |
3 | Mathieu Desnoyers 18-05-2004 |
4 | |
5 | |
6 | Seeing that a very precise hook call ordering is needed when processing events |
7 | (especially the order for calling state update hooks and event delivery hooks), |
8 | this document defines a new type and interface that permits to merge all kind of |
9 | hooks, eventually sorted by the priority associated to them. |
10 | |
11 | As the LttvHooksById has never been used up to this point in the project, I |
12 | doubt that any real need for it exists. If we still want to implement it, it |
13 | would require to create temporary by_id hook lists, add all the specific by_id |
14 | hooks and the main hooks to it, and sort it before the traceset reading starts. |
15 | |
16 | - Type LttvHooksPrio |
17 | |
18 | This is a new type containing hooks associated with a priority. It has its own |
19 | interface which pretty much looks like the one found in hook.h, plus the fact |
20 | that a priority is associated with each hook. (lttv_hooks_prio_add, |
21 | lttv_hooks_prio_call, lttv_hooks_prio_remove are sample names of functions |
22 | offered by this interface) The container for this type would be a garray, just |
23 | like hook.c, but a lttv_hooks_prio_sort would be required in order to sort the |
24 | array before using lttv_hooks_prio_call. |
25 | |
26 | The viewers will just have to pass hooks to the main window through this type, |
27 | using the hookprio.h interface to manipulate it. Then, the main window will add |
28 | them and remove them from the context to deliver exactly the events requested by |
29 | each viewer through process traceset. |
30 | |
31 | If we want to make this data type more encapsulated, we could call |
32 | lttv_hooks_prio_sort upon each modification to the structure. Then, a simple |
33 | lttv_hooks_prio_call would be assured to call the hooks in the right order. |
34 | |
35 | |