[lttv.git] / ltt / branches / poly / doc / developer / requests_servicing_schedulers.txt

Linux Trace Toolkit

Requests Servicing Schedulers


Mathieu Desnoyers, 07/06/2004


In the LTT graphical interface, two main types of events requests may occur :

- events requests made by a viewer concerning a traceset for a ad hoc
  computation.
- events requests made by a viewer concerning a trace for a precomputation.


Ad Hoc Computation

The ad hoc computation must be serviced immediately : they are directly
responding to events requests that must be serviced to complete the graphical
widgets'data. This kind of computation may lead to incomplete result as long as
precomputation are not finished. Once precomputation is over, the widgets will
be redrawn if they needed such information. A ad hoc computation is done on a
traceset : the workspace of a tab.

Precomputation 

Traces are global objects. Only one instance of a trace is opened for all the
program. Precomputation will append data to the traces attributes (states,
statistics). It must inform the widgets which asked for such states or
statistics of their availability. Only one precomputation must be launched for
each trace and no duplication of precomputation must be done.


Schedulers

There is one tracesetcontext per traceset. Each reference to a trace by a
traceset also has its own tracecontext. Each trace, by itself, has its own
tracecontext.

Let's define a scheduler as a g_idle events request servicing function.

There is one scheduler per traceset context (registered when there are requests
to answer). There is also one scheduler per autonomous trace context (not
related to any traceset context).

A scheduler processes requests for a specific traceset or trace by combining
time intervals of the requests. It is interruptible by any GTK event. A
precomputation scheduler has a lower priority than a ad hoc computation
scheduler. That means that no precomputation will be performed until there is
no more ad hoc compuation pending. When a scheduler is interrupted, it makes no
assumption about the presence or absence of the current requests in its pool
when it starts back.


Foreground Scheduler

There can be one foreground scheduler per traceset (one traceset per tab). It
simply calls the hooks given by the events requests of the viewers for the
specified time intervals.


Background Scheduler

It has its own events requests pool. It services them just like a foreground
scheduler. The difference comes in that there may be duplicated requests :
for instance, statistics computation for a trace can be asked by two viewers
at the same time. Another difference is that the hook_data of theses requests
will typically be NULL, and the typical hook function will be located in a
library upon which the viewer depends.

A viewer is informed of the completeness of part of its request by its
after_traceset hook registered along with the events request. This hook is
called after the end of each chunk : the viewer will see if the computed data
suits its needs.


Hooks Lists

In order to answer the problems of background processing, we need to add a
reference counter for each hook of a hook list. If the same hook is added twice,
it will be called only once, but it will need two "remove" to be really removed
from the list. Two hooks are identical if they have the same function pointer
and hook_data.


Implementation

Ad Hoc Computation

see lttvwindow_events_delivery.txt


Hooks Lists

need new ref_count field with each hook
lttv_hook_add and lttv_hook_add_list must compare addition with present and
increment ref counter if already present.

lttv_hook_remove and remove_with_data must decrement ref_count is >1, or remove
the element otherwise (==1).


Background Scheduler

Global traces

Two global attributes per trace : 
/traces/path_to_trace/LttvTrace
  It is a pointer to the LttvTrace structure.
/traces/path_to_trace/LttvBackgroundComputation

struct _LttvBackgroundComputation {
  GSList *events_requests;
 /* A GSList * to the first events request of background computation for a
  * trace. */
  LttvTraceset *ts;
 /* A factice traceset that contains just one trace */
  LttvTracesetContext *tsc;
 /* The traceset context that reads this trace */
}


Modify Traceset
Points to the global traces. Opens new one only when no instance of the pathname
exists.

Modify LttvTrace ?

Modify trace opening / close to make them create and destroy
LttvBackgroundComputation (and call end requests hooks for servicing requests ?)

EventsRequest Structure

This structure is the element of the events requests pools. The viewer field is
used as an ownership identifier as well as pointer to the data structure upon
which the action applies. Typically, this is a pointer to the viewer's data
structure.

In a ad hoc events request, a pointer to this structure is used as hook_data in
the hook lists

The typical case for a background computation is that the hook_data will be set
to NULL instead. No particular hook_data is needed as this type of request does
only modify trace related data structures which are available through the
call_data.
Commit	Line	Data
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
63b8a718	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.
ca566f70	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
63b8a718	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
ca566f70	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