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