ca566f70 |
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 | |
63b8a718 |
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. |
ca566f70 |
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 | |
63b8a718 |
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 | |
ca566f70 |
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 | |