| 1 | Linux Trace Toolkit |
| 2 | |
| 3 | Requests Servicing Schedulers |
| 4 | |
| 5 | |
| 6 | Mathieu Desnoyers, 07/06/2004 |
| 7 | |
| 8 | |
| 9 | In the LTT graphical interface, two main types of events requests may occur : |
| 10 | |
| 11 | - events requests made by a viewer concerning a traceset for a ad hoc |
| 12 | computation. |
| 13 | - events requests made by a viewer concerning a trace for a precomputation. |
| 14 | |
| 15 | |
| 16 | Ad Hoc Computation |
| 17 | |
| 18 | The ad hoc computation must be serviced immediately : they are directly |
| 19 | responding to events requests that must be serviced to complete the graphical |
| 20 | widgets'data. This kind of computation may lead to incomplete result as long as |
| 21 | precomputation are not finished. Once precomputation is over, the widgets will |
| 22 | be redrawn if they needed such information. A ad hoc computation is done on a |
| 23 | traceset : the workspace of a tab. |
| 24 | |
| 25 | Precomputation |
| 26 | |
| 27 | Traces are global objects. Only one instance of a trace is opened for all the |
| 28 | program. Precomputation will append data to the traces attributes (states, |
| 29 | statistics). It must inform the widgets which asked for such states or |
| 30 | statistics of their availability. Only one precomputation must be launched for |
| 31 | each trace and no duplication of precomputation must be done. |
| 32 | |
| 33 | |
| 34 | Schedulers |
| 35 | |
| 36 | There is one tracesetcontext per traceset. Each reference to a trace by a |
| 37 | traceset also has its own tracecontext. Each trace, by itself, has its own |
| 38 | tracecontext. |
| 39 | |
| 40 | Let's define a scheduler as a g_idle events request servicing function. |
| 41 | |
| 42 | There is one scheduler per traceset context (registered when there are requests |
| 43 | to answer). There is also one scheduler per autonomous trace context (not |
| 44 | related to any traceset context). |
| 45 | |
| 46 | A scheduler processes requests for a specific traceset or trace by combining |
| 47 | time intervals of the requests. It is interruptible by any GTK event. A |
| 48 | precomputation scheduler has a lower priority than a ad hoc computation |
| 49 | scheduler. That means that no precomputation will be performed until there is |
| 50 | no more ad hoc compuation pending. When a scheduler is interrupted, it makes no |
| 51 | assumption about the presence or absence of the current requests in its pool |
| 52 | when it starts back. |
| 53 | |
| 54 | |
| 55 | Foreground Scheduler |
| 56 | |
| 57 | There can be one foreground scheduler per traceset (one traceset per tab). It |
| 58 | simply calls the hooks given by the events requests of the viewers for the |
| 59 | specified time intervals. |
| 60 | |
| 61 | |
| 62 | Background Scheduler |
| 63 | |
| 64 | It has its own events requests pool. It services them just like a foreground |
| 65 | scheduler. The difference comes in that there may be duplicated requests : |
| 66 | for instance, statistics computation for a trace can be asked by two viewers |
| 67 | at the same time. Another difference is that the hook_data of theses requests |
| 68 | will typically be NULL, and the typical hook function will be located in a |
| 69 | library upon which the viewer depends. |
| 70 | |
| 71 | A viewer is informed of the completeness of part of its request by its |
| 72 | after_traceset hook registered along with the events request. This hook is |
| 73 | called after the end of each chunk : the viewer will see if the computed data |
| 74 | suits its needs. |
| 75 | |
| 76 | |
| 77 | Hooks Lists |
| 78 | |
| 79 | In order to answer the problems of background processing, we need to add a |
| 80 | reference counter for each hook of a hook list. If the same hook is added twice, |
| 81 | it will be called only once, but it will need two "remove" to be really removed |
| 82 | from the list. Two hooks are identical if they have the same function pointer |
| 83 | and hook_data. |
| 84 | |
| 85 | |
| 86 | |
| 87 | Implementation |
| 88 | |
| 89 | Ad Hoc Computation |
| 90 | |
| 91 | see lttvwindow_events_delivery.txt |
| 92 | |
| 93 | |
| 94 | Hooks Lists |
| 95 | |
| 96 | need new ref_count field with each hook |
| 97 | lttv_hook_add and lttv_hook_add_list must compare addition with present and |
| 98 | increment ref counter if already present. |
| 99 | |
| 100 | lttv_hook_remove and remove_with_data must decrement ref_count is >1, or remove |
| 101 | the element otherwise (==1). |
| 102 | |
| 103 | |
| 104 | |
| 105 | Background Scheduler |
| 106 | |
| 107 | Global traces |
| 108 | |
| 109 | Two global attributes per trace : |
| 110 | /traces/path_to_trace/LttvTrace |
| 111 | It is a pointer to the LttvTrace structure. |
| 112 | /traces/path_to_trace/LttvBackgroundComputation |
| 113 | |
| 114 | struct _LttvBackgroundComputation { |
| 115 | GSList *events_requests; |
| 116 | /* A GSList * to the first events request of background computation for a |
| 117 | * trace. */ |
| 118 | LttvTraceset *ts; |
| 119 | /* A factice traceset that contains just one trace */ |
| 120 | LttvTracesetContext *tsc; |
| 121 | /* The traceset context that reads this trace */ |
| 122 | } |
| 123 | |
| 124 | |
| 125 | |
| 126 | |
| 127 | Modify Traceset |
| 128 | Points to the global traces. Opens new one only when no instance of the pathname |
| 129 | exists. |
| 130 | |
| 131 | Modify LttvTrace ? |
| 132 | |
| 133 | Modify trace opening / close to make them create and destroy |
| 134 | LttvBackgroundComputation (and call end requests hooks for servicing requests ?) |
| 135 | |
| 136 | EventsRequest Structure |
| 137 | |
| 138 | This structure is the element of the events requests pools. The viewer field is |
| 139 | used as an ownership identifier as well as pointer to the data structure upon |
| 140 | which the action applies. Typically, this is a pointer to the viewer's data |
| 141 | structure. |
| 142 | |
| 143 | In a ad hoc events request, a pointer to this structure is used as hook_data in |
| 144 | the hook lists |
| 145 | |
| 146 | The typical case for a background computation is that the hook_data will be set |
| 147 | to NULL instead. No particular hook_data is needed as this type of request does |
| 148 | only modify trace related data structures which are available through the |
| 149 | call_data. |
| 150 | |