| 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 its request by its after_request |
| 72 | hook registered along with the events request. |
| 73 | |
| 74 | |
| 75 | Hooks Lists |
| 76 | |
| 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 |
| 81 | and hook_data. |
| 82 | |
| 83 | |
| 84 | EventsRequest Structure |
| 85 | |
| 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 |
| 89 | structure. |
| 90 | |
| 91 | In a ad hoc events request, a pointer to this structure is used as hook_data in |
| 92 | the hook lists |
| 93 | |
| 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 |
| 97 | call_data. |
| 98 | |
| 99 | |
| 100 | |