ltt/branches/poly/doc/developer/requests_servicing_schedulers.txt

   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 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.
  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
  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
 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