6ea2aecb |
1 | Linux Trace Toolkit |
2 | |
3 | Mathieu Desnoyers 17-05-2004 |
4 | |
5 | |
6 | This document explains how the lttvwindow API could process the event requests |
7 | of the viewers, merging event requests and hook lists to benefit from the fact |
8 | that process_traceset can call multiple hooks for the same event. |
9 | |
10 | First, we will explain the detailed process of event delivery in the current |
11 | framework. We will then study its strengths and weaknesses. |
12 | |
13 | In a second time, a framework where the events requests are dealt by the main |
14 | window with fine granularity will be described. We will then discussed the |
15 | advantages and inconvenients over the first framework. |
16 | |
17 | |
18 | 1. (Actual) Boundaryless event reading |
19 | |
20 | Actually, viewers request events in a time interval from the main window. They |
21 | also specify a (not so) maximum number of events to be delivered. In fact, the |
22 | number of events to read only gives a stop point, from where only events with |
23 | the same timestamp will be delivered. |
24 | |
25 | Viewers register hooks themselves in the traceset context. When merging read |
26 | requests in the main window, all hooks registered by viewers will be called for |
27 | the union of all the read requests, because the main window has no control on |
28 | hook registration. |
29 | |
30 | The main window calls process_traceset on its own for all the intervals |
31 | requested by all the viewers. It must not duplicate a read of the same time |
32 | interval : it could be very hard to filter by viewers. So, in order to achieve |
33 | this, time requests are sorted by start time, and process_traceset is called for |
34 | each time request. We keep the last event time between each read : if the start |
35 | time of the next read is lower than the time reached, we continue the reading |
36 | from the actual position. |
37 | |
38 | We deal with specific number of events requests (infinite end time) by |
39 | garantying that, starting from the time start of the request, at least that |
40 | number of events will be read. As we can't do it efficiently without interacting |
41 | very closely with process_traceset, we always read the specified number of |
42 | events requested starting from the current position when we answer to a request |
43 | based on the number of events. |
44 | |
45 | The viewers have to filter events delivered by traceset reading, because they |
46 | can be asked by another viewer for a totally (or partially) different time |
47 | interval. |
48 | |
49 | |
50 | Weaknesses |
51 | |
52 | - process_middle does not guarantee the number of events read |
53 | |
54 | First of all, a viewer that requests events to process_traceset has no garantee |
55 | that it will get exactly what it asked for. For example, a direct call to |
56 | traceset_middle for a specific number of events will delived _at least_ that |
57 | quantity of events, plus the ones that have the same timestamp that the last one |
58 | has. |
59 | |
60 | - Border effects |
61 | |
62 | Viewer's writers will have to deal with a lot of border effects caused by the |
318585ee |
63 | particularities of the reading. They will be required to select the information |
64 | they need from their input by filtering. |
6ea2aecb |
65 | |
318585ee |
66 | - Lack of encapsulation and difficulty of testing |
6ea2aecb |
67 | |
68 | The viewer's writer will have to take into account all the border effects caused |
69 | by the interaction with other modules. This means that event if a viewer works |
70 | well alone or with another viewer, it's possible that new bugs arises when a new |
318585ee |
71 | viewer comes around. So, even if a perfect testbench works well for a viewer, it |
72 | does not confirm that no new bug will arise when another viewer is loaded at the |
73 | same moment asking for different time intervals. |
6ea2aecb |
74 | |
75 | |
76 | - Duplication of the work |
77 | |
78 | Time based filters and counters of events will have to be implemented at the |
79 | viewer's side, which is a duplication of the functionnalities that would |
80 | normally be expected from the tracecontext API. |
81 | |
82 | - Lack of control over the data input |
83 | |
84 | As we expect module's writers to prefer to be as close as possible from the raw |
85 | datas, making them interact with a lower level library that gives them a data |
86 | input that they only control by further filtering of the input is not |
87 | appropriated. We should expect some reluctancy from them about using this API |
88 | because of this lack of control on the input. |
89 | |
90 | - Speed cost |
91 | |
92 | All hooks of all viewers will be called for all the time intervals. So, if we |
93 | have a detailed events list and a control flow view, asking both for different |
94 | time intervals, the detailed events list will have to filter all the events |
95 | delivered originally to the control flow view. This can be a case occuring quite |
96 | often. |
97 | |
98 | |
99 | |
100 | Strengths |
101 | |
102 | - Simple concatenation of time intervals at the main window level. |
103 | |
104 | Having the opportunity of delivering more events than necessary to the viewers |
105 | means that we can concatenate time intervals and number of events requested |
106 | fairly easily, while being hard to determine if some specific cases will be |
318585ee |
107 | wrong, in depth testing being impossible. |
6ea2aecb |
108 | |
109 | - No duplication of the tracecontext API |
110 | |
111 | Viewers deal directly with the tracecontext API for registering hooks, removing |
112 | a layer of encapsulation. |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | 2. (Proposed) Strict boundaries events reading |
119 | |
120 | The idea behind this method is to provide exactly the events requested by the |
121 | viewers to them, no more, no less. |
122 | |
6ea2aecb |
123 | It uses the new API for process traceset suggested in the document |
124 | process_traceset_strict_boundaries.txt. |
125 | |
126 | It also means that the lttvwindow API will have to deal with viewer's hooks. |
127 | Those will not be allowed to add them directly in the context. They will give |
128 | them to the lttvwindow API, along with the time interval or the position and |
129 | number of events. The lttvwindow API will have to take care of adding and |
130 | removing hooks for the different time intervals requested. That means that hooks |
131 | insertion and removal will be done between each traceset processing based on |
132 | the time intervals and event positions related to each hook. We must therefore |
133 | provide a simple interface for hooks passing between the viewers and the main |
318585ee |
134 | window, make them easier to manage from the main window. A modification to the |
135 | LttvHooks type solves this problem. |
6ea2aecb |
136 | |
137 | |
138 | Architecture |
139 | |
140 | Added to the lttvwindow API : |
141 | |
142 | |
8646cedb |
143 | void lttvwindow_events_request |
144 | ( MainWindow *main_win, |
145 | EventsRequest events_request); |
6ea2aecb |
146 | |
8646cedb |
147 | void lttvwindow_events_request_remove_all |
148 | ( MainWindow *main_win, |
149 | gpointer viewer); |
6ea2aecb |
150 | |
6ea2aecb |
151 | |
8646cedb |
152 | Internal functions : |
6ea2aecb |
153 | |
154 | - lttvwindow_process_pending_requests |
155 | |
318585ee |
156 | |
8646cedb |
157 | Events Requests Removal |
318585ee |
158 | |
8646cedb |
159 | A new API function will be necessary to let viewers remove all event requests |
160 | they have made previously. By allowing this, no more out of bound requests will |
161 | be serviced : a viewer that sees its time interval changed before the first |
162 | servicing is completed can clear its previous events requests and make a new |
163 | one for the new interval needed, considering the finished chunks as completed |
164 | area. |
318585ee |
165 | |
8646cedb |
166 | It is also very useful for dealing with the viewer destruction case : the viewer |
167 | just has to remove its events requests from the main window before it gets |
168 | destroyed. |
318585ee |
169 | |
318585ee |
170 | |
8646cedb |
171 | Permitted GTK Events Between Chunks |
318585ee |
172 | |
8646cedb |
173 | All GTK Events will be enabled between chunks. This is due to the fact that the |
174 | background processing and a high priority request are seen as the same case. |
175 | While a background processing is in progress, the whole graphical interface must |
176 | be enabled. |
318585ee |
177 | |
8646cedb |
178 | We needed to deal with the coherence of background processing and diverse GTK |
179 | events anyway. This algorithm provides a generalized way to deal with any type |
180 | of request and any GTK events. |
318585ee |
181 | |
318585ee |
182 | |
8646cedb |
183 | Background Computation Request |
318585ee |
184 | |
8646cedb |
185 | The types of background computation that can be requested by a viewer : state |
186 | computation (main window scope) or viewer specific background computation. |
318585ee |
187 | |
8646cedb |
188 | A background computation request is asked via lttvwindow_events_request, with a |
189 | priority field set with a low priority. |
6ea2aecb |
190 | |
8646cedb |
191 | If a lttvwindow_events_request_remove_all is done on the viewer pointer, it will |
192 | not affect the state computation as no viewer pointer will have been passed in |
193 | the initial request. This is the expected result. For the background processings |
194 | that call viewer's hooks, they will be removed. |
6ea2aecb |
195 | |
196 | |
206ea1f4 |
197 | A New "Redraw" Button |
198 | |
199 | It will be used to redraw the viewers entirely. It is useful to restart the |
200 | servicing after a "stop" action. |
201 | |
202 | A New "Continue" Button |
203 | |
204 | It will tell the viewers to send requests for damaged areas. It is useful to |
205 | complete the servicing after a "stop" action. |
206 | |
207 | |
6ea2aecb |
208 | |
65bc0600 |
209 | Tab change |
210 | |
211 | If a tab change occurs, we still want to do background processing. |
212 | Events requests must be stocked in a list located in the same scope than the |
213 | traceset context. Right now, this is tab scope. All functions called from the |
214 | request servicing function must _not_ use the current_tab concept, as it may |
215 | change. The idle function must the take a tab, and not the main window, as |
216 | parameter. |
217 | |
218 | If a tab is removed, its associated idle events requests servicing function must |
219 | also be removed. |
220 | |
4a97e95b |
221 | It now looks a lot more useful to give a Tab* to the viewer instead of a |
222 | MainWindow*, as all the information needed by the viewer is located at the tab |
223 | level. It will diminish the dependance upon the current tab concept. |
224 | |
65bc0600 |
225 | |
226 | |
227 | Idle function (lttvwindow_process_pending_requests) |
228 | |
229 | The idle function must return FALSE to be removed from the idle functions when |
230 | no more events requests are pending. Otherwise, it returns TRUE. It will service |
231 | requests until there is no more request left. |
232 | |
233 | |
234 | |
235 | |
8646cedb |
236 | Implementation |
6ea2aecb |
237 | |
6ea2aecb |
238 | |
8646cedb |
239 | - Type LttvHooks |
6ea2aecb |
240 | |
8646cedb |
241 | see hook_prio.txt |
69381fc7 |
242 | |
8646cedb |
243 | The viewers will just have to pass hooks to the main window through this type, |
244 | using the hook.h interface to manipulate it. Then, the main window will add |
245 | them and remove them from the context to deliver exactly the events requested by |
246 | each viewer through process traceset. |
69381fc7 |
247 | |
248 | |
8646cedb |
249 | - lttvwindow_events_request |
69381fc7 |
250 | |
8646cedb |
251 | It adds the an EventsRequest struct to the array of time requests |
252 | pending and registers a pending request for the next g_idle if none is |
253 | registered. The viewer can access this structure during the read as its |
254 | hook_data. Only the stop_flag can be changed by the viewer through the |
255 | event hooks. |
69381fc7 |
256 | |
257 | typedef LttvEventsRequestPrio guint; |
258 | |
259 | typedef struct _EventsRequest { |
260 | gpointer viewer_data; |
261 | gboolean servicing; /* service in progress: TRUE */ |
262 | LttvEventsRequestPrio prio; /* Ev. Req. priority */ |
263 | LttTime start_time; /* Unset : { 0, 0 } */ |
264 | LttvTracesetContextPosition *start_position; /* Unset : num_traces = 0 */ |
265 | gboolean stop_flag; /* Continue:TRUE Stop:FALSE */ |
266 | LttTime end_time; /* Unset : { 0, 0 } */ |
267 | guint num_events; /* Unset : G_MAXUINT */ |
268 | LttvTracesetContextPosition *end_position; /* Unset : num_traces = 0 */ |
269 | LttvHooks *before_traceset; /* Unset : NULL */ |
270 | LttvHooks *before_trace; /* Unset : NULL */ |
271 | LttvHooks *before_tracefile;/* Unset : NULL */ |
272 | LttvHooks *event; /* Unset : NULL */ |
273 | LttvHooksById *event_by_id; /* Unset : NULL */ |
274 | LttvHooks *after_tracefile; /* Unset : NULL */ |
275 | LttvHooks *after_trace; /* Unset : NULL */ |
276 | LttvHooks *after_traceset; /* Unset : NULL */ |
277 | LttvHooks *before_chunk; /* Unset : NULL */ |
278 | LttvHooks *after_chunk /* Unset : NULL */ |
279 | } EventsRequest; |
280 | |
281 | |
8646cedb |
282 | |
283 | - lttvwindow_events_request_remove_all |
284 | |
285 | It removes all the events requests from the pool that has their "viewer" field |
286 | maching the viewer pointer given in argument. |
287 | |
288 | It calls the traceset/trace/tracefile end hooks for each request removed. |
289 | |
290 | |
291 | - lttvwindow_process_pending_requests |
292 | |
293 | This internal function gets called by g_idle, taking care of the pending |
294 | requests. It is responsible for concatenation of time intervals and position |
295 | requests. It does it with the following algorithm organizing process traceset |
296 | calls. Here is the detailed description of the way it works : |
297 | |
298 | |
299 | |
300 | - Revised Events Requests Servicing Algorithm (v2) |
301 | |
69381fc7 |
302 | The reads are splitted in chunks. After a chunk is over, we want to check if |
303 | there is a GTK Event pending and execute it. It can add or remove events |
304 | requests from the event requests list. If it happens, we want to start over |
305 | the algorithm from the beginning. |
306 | |
307 | Two levels of priority exists. High priority and low priority. High prio |
308 | requests are serviced first, even if lower priority requests has lower start |
309 | time or position. |
310 | |
311 | |
312 | Data structures necessary : |
313 | |
314 | List of requests added to context : list_in |
315 | List of requests not added to context : list_out |
316 | |
317 | Initial state : |
318 | |
319 | list_in : empty |
320 | list_out : many events requests |
321 | |
322 | |
323 | A. While list_in !empty and list_out !empty and !GTK Event pending |
324 | 1. If list_in is empty (need a seek) |
325 | 1.1 Add requests to list_in |
326 | 1.1.1 Find all time requests with the highest priority and lowest start |
327 | time in list_out (ltime) |
328 | 1.1.2 Find all position requests with the highest priority and lowest |
329 | position in list_out (lpos) |
330 | 1.1.3 If lpos.prio > ltime.prio |
331 | || (lpos.prio == ltime.prio && lpos.start time < ltime) |
332 | - Add lpos to list_in, remove them from list_out |
333 | 1.1.4 Else, (lpos.prio < ltime.prio |
334 | ||(lpos.prio == ltime.prio && lpos.start time >= ltime)) |
335 | - Add ltime to list_in, remove them from list_out |
336 | 1.2 Seek |
337 | 1.2.1 If first request in list_in is a time request |
e6359327 |
338 | - If first req in list_in start time != current time |
339 | - Seek to that time |
69381fc7 |
340 | 1.2.2 Else, the first request in list_in is a position request |
e6359327 |
341 | - If first req in list_in pos != current pos |
342 | - If the position is the same than the saved state, restore state |
343 | - Else, seek to that position |
69381fc7 |
344 | 1.3 Add hooks and call begin for all list_in members |
345 | 1.3.1 If !servicing |
346 | - begin hooks called |
347 | - servicing = TRUE |
348 | 1.3.2 call before_chunk |
349 | 1.3.3 events hooks added |
350 | 2. Else, list_in is not empty, we continue a read |
351 | 2.1 For each req of list_out |
352 | - if req.start time == current context time |
353 | - Add to list_in, remove from list_out |
354 | - If !servicing |
355 | - Call begin |
356 | - servicing = TRUE |
357 | - Call before_chunk |
358 | - events hooks added |
359 | - if req.start position == current position |
360 | - Add to list_in, remove from list_out |
361 | - If !servicing |
362 | - Call begin |
363 | - servicing = TRUE |
364 | - Call before_chunk |
365 | - events hooks added |
366 | |
367 | 3. Find end criterions |
368 | 3.1 End time |
369 | 3.1.1 Find lowest end time in list_in |
370 | 3.1.2 Find lowest start time in list_out (>= than current time*) |
371 | * To eliminate lower prio requests |
372 | 3.1.3 Use lowest of both as end time |
373 | 3.2 Number of events |
374 | 3.2.1 Find lowest number of events in list_in |
375 | 3.2.2 Use min(CHUNK_NUM_EVENTS, min num events in list_in) as num_events |
376 | 3.3 End position |
377 | 3.3.1 Find lowest end position in list_in |
378 | 3.3.2 Find lowest start position in list_out (>= than current |
379 | position) |
380 | 3.3.3 Use lowest of both as end position |
381 | |
382 | 4. Call process traceset middle |
383 | 4.1 Call process traceset middle (Use end criterion found in 3) |
384 | * note : end criterion can also be viewer's hook returning TRUE |
385 | 5. After process traceset middle |
386 | - if current context time > traceset.end time |
387 | - For each req in list_in |
388 | - Call end for req |
389 | - Remove events hooks for req |
390 | - remove req from list_in |
391 | 5.1 For each req in list_in |
392 | - req.num -= count |
393 | - if req.num == 0 |
394 | - Call end for req |
395 | - Remove events hooks for req |
396 | - remove req from list_in |
397 | - if current context time > req.end time |
398 | - Call end for req |
399 | - Remove events hooks for req |
400 | - remove req from list_in |
401 | - if req.end pos == current pos |
402 | - Call end for req |
403 | - Remove events hooks for req |
404 | - remove req from list_in |
405 | - if req.stop_flag == TRUE |
406 | - Call end for req |
407 | - Remove events hooks for req |
408 | - remove req from list_in |
409 | - if exists one events requests in list_out that has |
410 | higher priority and time != current time |
411 | - Use current position as start position for req |
412 | - Remove start time from req |
413 | - Call after_chunk for req |
414 | - Remove event hooks for req |
415 | - Put req back in list_out, remove from list_in |
416 | - Save current state into saved_state. |
417 | |
418 | B. When interrupted |
419 | 1. for each request in list_in |
420 | 1.1. Use current postition as start position |
421 | 1.2. Remove start time |
422 | 1.3. Call after_chunk |
423 | 1.4. Remove event hooks |
424 | 1.5. Put it back in list_out |
425 | 2. Save current state into saved_state. |
426 | 2.1 Free old saved state. |
427 | 2.2 save current state. |
428 | |
429 | |
430 | |
431 | |
432 | |
433 | Notes : |
434 | End criterions for process traceset middle : |
435 | If the criterion is reached, event is out of boundaries and we return. |
436 | Current time >= End time |
437 | Event count > Number of events |
438 | Current position >= End position |
439 | Last hook list called returned TRUE |
440 | |
441 | The >= for position is necessary to make ensure consistency between start time |
442 | requests and positions requests that happens to be at the exact same start time |
443 | and position. |
444 | |
445 | We only keep one saved state in memory. If, for example, a low priority |
446 | servicing is interrupted, a high priority is serviced, then the low priority |
447 | will use the saved state to start back where it was instead of seeking to the |
448 | time. In the very specific case where a low priority servicing is interrupted, |
449 | and then a high priority servicing on top of it is also interrupted, well, the |
450 | low priority will loose its state and will have to seek back. It should not |
451 | occur often. The solution to it would be to save one state per priority. |
452 | |
453 | |
8646cedb |
454 | |
455 | |
456 | |
457 | |
458 | Weaknesses |
459 | |
4bcbbd42 |
460 | - There is a possibility that we must use seek if more than one interruption |
461 | occurs, i.e. low priority interrupted by addition of high priority, and then |
462 | high priority interrupted. The seek will be necessary for the low priority. |
463 | It could be a good idea to keep one saved_state per priority ? |
8646cedb |
464 | |
465 | |
466 | Strengths |
467 | |
468 | - Removes the need for filtering of information supplied to the viewers. |
469 | |
470 | - Viewers have a better control on their data input. |
471 | |
472 | - Solves all the weaknesses idenfied in the actual boundaryless traceset |
473 | reading. |
474 | |
475 | - Background processing available. |
476 | |