--- /dev/null
+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
+
+Right now, to simplify the problem of the background scheduler, we assume that
+the module that loads the extended statistics hooks has been loaded before the
+data is requested and that it is not unloaded until the program stops. We will
+eventually have to deal with the requests removal based on module load/unload,
+but it complicates the problem quite a bit.
+
+A background scheduler adds hooks located under a global attributes path
+(specified by the viewer who makes the request) to the trace's traceset
+context (the trace is specified by the viewer). Then, it processes the whole
+trace with this context (and hooks).
+
+Typically, a module that extends statistics will register hooks in the global
+attributes tree under /computation/modulename/hook_name . A viewer
+that needs these statistics for a set of traces does a background computation
+request through a call to the main window API function. It must specify all
+types of hooks that must be called for the specified trace.
+
+The background computation requests for a trace are queued. When the idle
+function kicks in to answer these requests, it add the hooks of all the requests
+toghether in the context and starts the read. It also keeps a list of the
+background requests currently serviced.
+
+The read is done from start to end of the trace, calling all the hooks present
+in the context. Only when the read is over, the after_request hooks of the
+currently serviced requests are called and the requests are destroyed.
+
+If there are requests in the waiting queue, they are all added to the current
+pool and processed. It is important to understand that, while a processing is in
+being done, no requests are added to the pool : they wait for their turn in the
+queue.
+
+Every hook that are added to the context by the scheduler comes from global
+attributes, i.e.
+/traces/#
+ in LttvTrace attributes : modulename/hook_name
+
+They come with a flag telling either in_progress or ready. If the flag
+ready is set, a viewer knows that the data it needs is already ready and he
+doesn't have to make a request.
+
+If the flag in_progress is set, that means that the data it needs is currently
+being serviced, and it must wait for the current servicing to be finished. It
+tells the lttvwindow API to call a hook when the actual servicing is over (there
+is a special function for this, as it requires to modify the pool of requests
+actually being serviced : we must make sure that no new reading hooks are
+added!).
+
+
+
+
+
+New Global Attributes
+
+/traces/#
+ in LttvTrace attributes :
+
+When a processing is fired, a variable
+ computation/modulename/in_progress is set.
+
+When a processing finished, a variable
+ computation/modulename/in_progress is unset
+ computation/modulename/ready is set
+
+
+
+
+
+Typical Use For a Viewer
+
+When a viewer wants extended information, it must first check if it is ready.
+if not :
+Before a viewer makes a request, it must check the in_progress status of the
+hooks.
+
+If the in_progress is unset, it makes the request.
+
+If the in_progress is set, it makes a special request for being informed of the
+end of request.
+
+
+
+
+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/#
+ It is a pointer to the LttvTrace structure.
+ In the LttvTrace attributes :
+ state/
+ saved_states/
+ statistics/
+ modes/
+ cpu/
+ processes/
+ modulename1/
+ modulename2/
+ ...
+ computation/ /* Trace specific background computation hooks status */
+ state/
+ in_progress
+ ready
+ stats/
+ in_progress
+ ready
+ modulename1/
+ in_progress
+ ready
+ requests_queue/ /* Background computation requests */
+ requests_current/ /* Type : BackgroundRequest */
+ notify_queue/
+ notify_current/
+ computation_traceset/
+ computation_traceset_context/
+
+
+computation/ /* Global background computation hooks */
+ state/
+ before_chunk_traceset
+ before_chunk_trace
+ before_chunk_tracefile
+ after_...
+ before_request
+ after_request
+ event_hook
+ event_hook_by_id
+ hook_adder
+ hook_remover
+ stats/
+ ...
+ modulename1/
+ ...
+
+Hook Adder and Hook remover
+
+Hook functions that takes a trace context as call data. They simply
+add / remove the computation related hooks from the trace context.
+
+
+
+Modify Traceset
+Points to the global traces. Main window must open a new one only when no
+instance of the pathname exists.
+
+Modify trace opening / close to make them create and destroy
+LttvBackgroundComputation (and call end requests hooks for servicing requests)
+and global trace info when references to the trace is zero.
+
+
+
+EventsRequest Structure
+
+This structure is the element of the events requests pools. The owner field is
+used as an ownership identifier. The viewer field is a pointer to the data
+structure upon which the action applies. Typically, both will be pointers to
+the viewer's data structure.
+
+In a ad hoc events request, a pointer to the EventsRequest structure is used as
+hook_data in the hook lists : it must have been added by the viewers.
+
+
+Modify module load/unload
+
+A module that registers global computation hooks in the global attributes upon
+load should unregister them when unloaded. Also, it must remove every background
+computation request for each trace that has its own module_name as GQuark.
+
+
+Give an API for calculation modules
+
+Must have an API for module which register calculation hooks. Unregistration
+must also remove all requests made for these hooks.
+
+
+Background Requests Servicing Algorithm (v1)
+
+
+list_in : currently serviced requests
+list_out : queue of requests waiting for processing
+
+notification lists :
+notify_in : currently checked notifications
+notify_out : queue of notifications that comes along with next processing.
+
+
+0.1 Lock traces
+0.2 Sync tracefiles
+
+1. Before processing
+ - if list_in is empty
+ - Add all requests in list_out to list_in, empty list_out
+ - for each request in list_in
+ - set hooks'in_progress flag to TRUE
+ - call before request hook
+ - seek trace to start
+ - Move all notifications from notify_out to notify_in.
+ - for each request in list_in
+ - Call before chunk hooks for list_in
+ - add hooks to context *note only one hook of each type added.
+
+2. call process traceset middle for a chunk
+ (assert list_in is not empty! : should not even be called in that case)
+
+3. After the chunk
+ 3.1 call after_chunk hooks for list_in
+ - for each request in list_in
+ - Call after chunk hooks for list_in
+ - remove hooks from context *note : only one hook of each type
+ 3.2 for each notify_in
+ - if current time >= notify time, call notify and remove from notify_in
+ - if current position >= notify position, call notify and remove from
+ notify_in
+ 3.3 if end of trace reached
+ - for each request in list_in
+ - set hooks'in_progress flag to FALSE
+ - set hooks'ready flag to TRUE
+ - call after request hook
+ - remove request
+ - for each notifications in notify_in
+ - call notify and remove from notify_in
+ - reset the context
+ - if list_out is empty
+ return FALSE (scheduler stopped)
+ - else
+ return TRUE (scheduler still registered)
+ 3.4 else
+ - return TRUE (scheduler still registered)
+
+4. Unlock traces
projects / lttv.git / blobdiff