basic lttvwindow works
[lttv.git] / ltt / branches / poly / doc / developer / lttvwindow_events_delivery.txt
index 2a7da4e0d6af010c10c3c63afa3bd349451b40ae..a3a785f5f5a563bd561fb51ec47c0a476a5f94cd 100644 (file)
@@ -60,14 +60,17 @@ has.
 - Border effects
 
 Viewer's writers will have to deal with a lot of border effects caused by the
-particularities of the reading by selecting the information.
+particularities of the reading. They will be required to select the information
+they need from their input by filtering.
 
-- Lack of encapsulation
+- Lack of encapsulation and difficulty of testing
 
 The viewer's writer will have to take into account all the border effects caused
 by the interaction with other modules. This means that event if a viewer works
 well alone or with another viewer, it's possible that new bugs arises when a new
-viewer comes around.
+viewer comes around. So, even if a perfect testbench works well for a viewer, it
+does not confirm that no new bug will arise when another viewer is loaded at the
+same moment asking for different time intervals.
 
 
 - Duplication of the work
@@ -101,7 +104,7 @@ Strengths
 Having the opportunity of delivering more events than necessary to the viewers
 means that we can concatenate time intervals and number of events requested
 fairly easily, while being hard to determine if some specific cases will be
-wrong by formal methods.
+wrong, in depth testing being impossible.
 
 - No duplication of the tracecontext API
 
@@ -117,10 +120,6 @@ a layer of encapsulation.
 The idea behind this method is to provide exactly the events requested by the
 viewers to them, no more, no less.
 
-This method relies on the fact that time based and number based event requests
-are, by nature, totally different and that there is no real interest in merging
-both requests types.
-
 It uses the new API for process traceset suggested in the document
 process_traceset_strict_boundaries.txt.
 
@@ -132,8 +131,8 @@ removing hooks for the different time intervals requested. That means that hooks
 insertion and removal will be done between each traceset processing based on
 the time intervals and event positions related to each hook. We must therefore
 provide a simple interface for hooks passing between the viewers and the main
-window, make them easier to manage from the main window. The new type
-LttvHooksPrio solves this problem.
+window, making them easier to manage from the main window. A modification to the
+LttvHooks type solves this problem.
 
 
 Architecture
@@ -141,21 +140,13 @@ Architecture
 Added to the lttvwindow API :
 
 
-- lttvwindow_time_interval_request
-arguments :
-( MainWindow *main_win,
-  TimeWindow time_requested, guint num_events,
-  LttvHooksPrio process_traceset_middle,
-  LttvHook after_process_traceset,
-  gpointer after_process_traceset_data);
+void lttvwindow_events_request
+( Tab                  *tab,
+  const EventsRequest  *events_request);
 
-- lttvwindow_position_request
-arguments :
-( MainWindow *main_win,
-  LttvTracesetPosition position, guint max_num_events,
-  LttvHooksPrio process_traceset_middle,
-  LttvHook after_process_traceset,
-  gpointer after_process_traceset_data);
+void lttvwindow_events_request_remove_all
+( Tab                *tab,
+  gconstpointer       viewer);
 
 
 Internal functions :
@@ -163,96 +154,258 @@ Internal functions :
 - lttvwindow_process_pending_requests
 
 
+Events Requests Removal
 
-Implementation
+A new API function will be necessary to let viewers remove all event requests
+they have made previously. By allowing this, no more out of bound requests will
+be serviced : a viewer that sees its time interval changed before the first
+servicing is completed can clear its previous events requests and make a new
+one for the new interval needed, considering the finished chunks as completed
+area.
 
+It is also very useful for dealing with the viewer destruction case : the viewer
+just has to remove its events requests from the main window before it gets
+destroyed.
 
-- Type LttvHooksPrio
 
-see hook_prio.h
+Permitted GTK Events Between Chunks
 
+All GTK Events will be enabled between chunks. A viewer could ask for a
+long computation that has no impact on the display : in that case, it is
+necessary to keep the graphical interface active. While a processing is in
+progress, the whole graphical interface must be enabled.
 
-- lttvwindow_time_interval_request
+We needed to deal with the coherence of background processing and diverse GTK
+events anyway. This algorithm provides a generalized way to deal with any type
+of request and any GTK events.
 
-It adds the TimeRequest struct to the array of time requests pending and
-registers a pending request for the next g_idle if none is registered.
 
-typedef struct _TimeRequest {
-  TimeWindow  time_window;
-  guint num_events;
-  LttvHooksPrio middle_hooks;
-  LttvHook after_hook;
-  gpointer after_hook_data;
-} TimeRequest;
+Background Computation Request
 
+A background computation has a trace scope, and is therefore not linked to a
+main window. It is not detailed in this document. 
+see requests_servicing_schedulers.txt
 
-- lttvwindow_position_request
+A New "Redraw" Button
 
-It adds a PositionRequest struct to the array of position requests pending and
-registers a pending request for the next g_idle if none is registered.
+It will be used to redraw the viewers entirely. It is useful to restart the
+servicing after a "stop" action.
 
-typedef struct _PositionRequest {
-  LttvTracesetPosition  position;
-  guint max_num_events;
-  LttvHooksPrio middle_hooks;
-  LttvHook after_hook;
-  gpointer after_hook_data;
-} PositionRequest;
+A New "Continue" Button
 
+It will tell the viewers to send requests for damaged areas. It is useful to
+complete the servicing after a "stop" action.
 
 
-- lttvwindow_process_pending_requests
 
-This internal function gets called by g_idle, taking care of the pending
-requests. It is responsible for concatenation of time intervals and position
-requests. It does it while it calls process traceset. Here is the detailed
-description of the way it works :
+Tab change
 
-It treats time interval requests and position requests as two different cases.
-So let's start with time interval requests.
+If a tab change occurs, we still want to do background processing.
+Events requests must be stocked in a list located in the same scope than the
+traceset context. Right now, this is tab scope. All functions called from the
+request servicing function must _not_ use the current_tab concept, as it may
+change. The idle function must the take a tab, and not the main window, as
+parameter.
 
-- Time interval requests servicing
+If a tab is removed, its associated idle events requests servicing function must
+also be removed.
 
-(1)
-It starts by finding the time interval request with the lowest start time and
-the others with the same start time. It add its (or their) hooks to the context.
-It will use this start time to seek in the traceset.
+It now looks a lot more useful to give a Tab* to the viewer instead of a
+MainWindow*, as all the information needed by the viewer is located at the tab
+level. It will diminish the dependance upon the current tab concept.
 
-Then, it searches for what event comes first : the end of one of the time
-request actually added in the context or the start of a time request that is not
-in the context. It uses this value as a end boundary for the first process
-traceset middle call.
 
-After a process traceset middle ends, we check if we have reached the end time
-of any time request. If so, we call the time requests process traceset end hook
-and remove this time request from the context and the array of time requests. If
-the context has no hooks left, that means that we have to jump further in the
-traceset. We then simply have to use the exact routine that we used for (1).
 
-Else, if there are hooks left, that means that we have not finished requesting
-one hook's time interval request yet, but maybe we must add a new time request
-to the hook list of the context. We start back at point (1), except that instead
-of finding the lowest start time, we simply keep the hooks already present in
-the context and add hooks that has their start time with a value equal to the
-last process traceset's end time.
+Idle function (lttvwindow_process_pending_requests)
 
+The idle function must return FALSE to be removed from the idle functions when
+no more events requests are pending. Otherwise, it returns TRUE. It will service
+requests until there is no more request left.
 
-- Position requests servicing
 
-As it is nearly impossible to compare two traceset positions without replaying
-part of the traceset reading, which is not very efficient, we consider that the
-performance cost of doing one trace read per request does not justify position
-requests combinations. So, each position request will be serviced independently.
 
+Implementation
 
 
+- Type LttvHooks
+
+see hook_prio.txt
+
+The viewers will just have to pass hooks to the main window through this type,
+using the hook.h interface to manipulate it. Then, the main window will add
+them and remove them from the context to deliver exactly the events requested by
+each viewer through process traceset.
+
+
+- lttvwindow_events_request
+
+It adds the an EventsRequest struct to the list of events requests
+pending and registers a pending request for the next g_idle if none is
+registered. The viewer can access this structure during the read as its
+hook_data. Only the stop_flag can be changed by the viewer through the
+event hooks.
+
+typedef struct _EventsRequest {
+  gpointer                     owner;           /* Owner of the request     */
+  gpointer                     viewer_data;     /* Unset : NULL             */
+  gboolean                     servicing;       /* service in progress: TRUE */ 
+  LttTime                      start_time;/* Unset : { G_MAXUINT, G_MAXUINT }*/
+  LttvTracesetContextPosition *start_position;  /* Unset : NULL             */
+  gboolean                     stop_flag;       /* Continue:TRUE Stop:FALSE */
+  LttTime                      end_time;/* Unset : { G_MAXUINT, G_MAXUINT } */
+  guint                        num_events;      /* Unset : G_MAXUINT        */
+  LttvTracesetContextPosition *end_position;    /* Unset : NULL             */
+  LttvHooks                   *before_chunk_traceset; /* Unset : NULL       */
+  LttvHooks                   *before_chunk_trace;    /* Unset : NULL       */
+  LttvHooks                   *before_chunk_tracefile;/* Unset : NULL       */
+  LttvHooks                   *event;           /* Unset : NULL             */
+  LttvHooksById               *event_by_id;     /* Unset : NULL             */
+  LttvHooks                   *after_chunk_tracefile; /* Unset : NULL       */
+  LttvHooks                   *after_chunk_trace;     /* Unset : NULL       */
+  LttvHooks                   *after_chunk_traceset;  /* Unset : NULL       */
+  LttvHooks                   *before_request;  /* Unset : NULL             */
+  LttvHooks                   *after_request;   /* Unset : NULL             */
+} EventsRequest;
 
-Weaknesses
 
-- Position requests are serviced independently, which may duplicate traceset
-reads.
+- lttvwindow_events_request_remove_all
 
+It removes all the events requests from the pool that has their "owner" field
+maching the owner pointer given as argument.
 
+It calls the traceset/trace/tracefile end hooks for each request removed if
+they are currently serviced.
+
+
+- lttvwindow_process_pending_requests
+
+This internal function gets called by g_idle, taking care of the pending
+requests. It is responsible for concatenation of time intervals and position
+requests. It does it with the following algorithm organizing process traceset
+calls. Here is the detailed description of the way it works :
+
+
+
+- Revised Events Requests Servicing Algorithm (v2)
+
+The reads are splitted in chunks. After a chunk is over, we want to check if
+there is a GTK Event pending and execute it. It can add or remove events 
+requests from the event requests list. If it happens, we want to start over
+the algorithm from the beginning. The after traceset/trace/tracefile hooks are
+called after each chunk, and before traceset/trace/tracefile are
+called when the request processing resumes. Before and after request hooks are
+called respectively before and after the request processing.
+
+
+Data structures necessary :
+
+List of requests added to context : list_in
+List of requests not added to context : list_out
+
+Initial state :
+
+list_in : empty
+list_out : many events requests
+
+
+A. While (list_in !empty or list_out !empty) and !GTK Event pending
+  1. If list_in is empty (need a seek)
+    1.1 Add requests to list_in
+      1.1.1 Find all time requests with lowest start time in list_out (ltime)
+      1.1.2 Find all position requests with lowest position in list_out (lpos)
+      1.1.3 If lpos.start time < ltime
+        - Add lpos to list_in, remove them from list_out
+      1.1.4 Else, (lpos.start time >= ltime)
+        - Add ltime to list_in, remove them from list_out
+    1.2 Seek
+      1.2.1 If first request in list_in is a time request
+        - If first req in list_in start time != current time
+          - Seek to that time
+      1.2.2 Else, the first request in list_in is a position request
+        - If first req in list_in pos != current pos
+          - seek to that position
+    1.3 Add hooks and call before request for all list_in members
+      1.3.1 If !servicing
+          - begin request hooks called
+          - servicing = TRUE
+      1.3.2 call before chunk
+      1.3.3 events hooks added
+  2. Else, list_in is not empty, we continue a read
+    2.1 For each req of list_out
+    - if req.start time == current context time
+              or req.start position == current position
+      - Add to list_in, remove from list_out
+      - If !servicing
+        - Call before request
+        - servicing = TRUE
+      - Call before chunk
+      - events hooks added
+
+  3. Find end criterions
+    3.1 End time
+      3.1.1 Find lowest end time in list_in
+      3.1.2 Find lowest start time in list_out (>= than current time*)
+                                * To eliminate lower prio requests (not used)
+      3.1.3 Use lowest of both as end time
+    3.2 Number of events
+      3.2.1 Find lowest number of events in list_in
+      3.2.2 Use min(CHUNK_NUM_EVENTS, min num events in list_in) as num_events
+    3.3 End position
+      3.3.1 Find lowest end position in list_in
+      3.3.2 Find lowest start position in list_out (>= than current
+                                                    position *not used)
+      3.3.3 Use lowest of both as end position
+
+  4. Call process traceset middle
+    4.1 Call process traceset middle (Use end criterion found in 3)
+      * note : end criterion can also be viewer's hook returning TRUE
+  5. After process traceset middle
+    - if current context time > traceset.end time
+      - For each req in list_in
+        - Remove events hooks for req
+        - Call end chunk for req
+        - Call end request for req
+        - remove req from list_in
+    5.1 For each req in list_in
+          - Call end chunk for req
+          - Remove events hooks for req
+          - req.num -= count
+          - if   req.num == 0
+               or
+                 current context time > req.end time
+               or
+                 req.end pos == current pos
+               or
+                 req.stop_flag == TRUE
+            - Call end request for req
+            - remove req from list_in
+
+B. When interrupted between chunks
+  1. for each request in list_in
+    1.1. Use current postition as start position
+    1.2. Remove start time
+    1.3. Move from list_in to list_out
+
+
+
+Notes :
+End criterions for process traceset middle :
+If the criterion is reached, event is out of boundaries and we return.
+Current time >= End time
+Event count > Number of events
+Current position >= End position
+Last hook list called returned TRUE
+
+The >= for position is necessary to make ensure consistency between start time
+requests and positions requests that happens to be at the exact same start time
+and position.
+
+
+
+
+Weaknesses
+
+- ?
 
 Strengths
 
@@ -262,3 +415,4 @@ Strengths
 
 - Solves all the weaknesses idenfied in the actual boundaryless traceset
 reading.
+
This page took 0.026192 seconds and 4 git commands to generate.