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 | |
71 | |
72 | |
73 | Hooks Lists |
74 | |
75 | In order to answer the problems of background processing, we need to add a |
76 | reference counter for each hook of a hook list. If the same hook is added twice, |
77 | it will be called only once, but it will need two "remove" to be really removed |
78 | from the list. Two hooks are identical if they have the same function pointer |
79 | and hook_data. |
80 | |
81 | |
82 | EventsRequest Structure |
83 | |
84 | This structure is the element of the events requests pools. The viewer field is |
85 | used as an ownership identifier as well as pointer to the data structure upon |
86 | which the action applies. Typically, this is a pointer to the viewer's data |
87 | structure. |
88 | |
89 | In a ad hoc events request, a pointer to this structure is used as hook_data in |
90 | the hook lists |
91 | |
92 | The typical case for a background computation is that the hook_data will be set |
93 | to NULL instead. No particular hook_data is needed as this type of request does |
94 | only modify trace related data structures which are available through the |
95 | call_data. |
96 | |
97 | |
98 | |