3 Requests Servicing Schedulers
6 Mathieu Desnoyers, 07/06/2004
9 In the LTT graphical interface, two main types of events requests may occur :
11 - events requests made by a viewer concerning a traceset for a ad hoc
13 - events requests made by a viewer concerning a trace for a precomputation.
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.
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.
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
40 Let's define a scheduler as a g_idle events request servicing function.
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).
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
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.
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.
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
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
91 see lttvwindow_events_delivery.txt
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.
100 lttv_hook_remove and remove_with_data must decrement ref_count is >1, or remove
101 the element otherwise (==1).
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
114 struct _LttvBackgroundComputation {
115 GSList *events_requests;
116 /* A GSList * to the first events request of background computation for a
119 /* A factice traceset that contains just one trace */
120 LttvTracesetContext *tsc;
121 /* The traceset context that reads this trace */
128 Points to the global traces. Opens new one only when no instance of the pathname
133 Modify trace opening / close to make them create and destroy
134 LttvBackgroundComputation (and call end requests hooks for servicing requests ?)
136 EventsRequest Structure
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
143 In a ad hoc events request, a pointer to this structure is used as hook_data in
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