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.
+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.
+
-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
+
+
+
Implementation
Ad Hoc Computation
Global traces
Two global attributes per trace :
-/traces/path_to_trace/LttvTrace
+traces/#
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 */
-}
-
+ 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. Opens new one only when no instance of the pathname
-exists.
-
-Modify LttvTrace ?
+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 ?)
+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 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.
+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.
-In a ad hoc events request, a pointer to this structure is used as hook_data in
-the hook lists
+2. call process traceset middle for a chunk
+ (assert list_in is not empty! : should not even be called in that case)
-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.
+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