| 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 | |