Re: EventViewer and time.

[Chris Moller <cmoller at redhat dot com>]

Events are stored per trace in the viewer, i.e., every trace structure
contains a pointer to an array containing the events associated with
that trace.  Within each event array, the events are chronologically
monotonic, but there's no correlation between different event arrays. 
What this means is that for Trace A, for example, you could have:

   1. 1    sec  eventA
   2. 1.1 sec  eventB
   3. 30  sec  eventC

It's easy enough to plot those events at uniform sequential intervals:

    A B C

but if Trace B has an eventD at 15 seconds, the result is

    A B    C
           D

i.e., you'll have to resequence Trace A to include a gap in which to put
EventD on Trace B.  The implication of all this is that you'll have to
either recompute the global sequence every time you expose, or maintain
a global chronologically monotonic event index, or some such thing. 
(Maybe something involving concurrent scans of all the event arrays...?)

Another potential complication is that I'd left the potential to have
the event timestamp accompany the event when it's stored.  The current
method--having the viewer generate and attach the timestamp
internally--is fine as long as all the events being recorded are being
generated on the same machine frysk is running on, but I seem to recall
(at least I designed for the possibility) that a single frysk instance
on one machine could monitor (by means TBD) events that occur remotely
on other machines.  If that indeed is ever actually implemented, the
remote machines will have to generate its own per-event timestamps. 
Failing to do that will introduce unpredictably inconsistent
transmission delays, potentially violating monotonicity  (i.e., if it
takes Machine B longer to transmit a record of the occurrence of EventA
than it takes to transmit EventB and frysk generates the timestamps when
it receives the events, it could appear that EventB occurred before
EventA).  The only way to make sure this doesn't happen is if Machine B
generates its own timestamps and frysk records them rather than
generating its own.  (With the current method of storing events, the
events need not be stored with chronological monotonicity--each event
contains its own timestamp and is thus independent of every other event.)

Chris

Nurdin Premji mumbled something on 07/19/06 16:02:
> I've been thinking about how the eventviewer represents events and I
> think in terms of a time-line it does this too realistically. What I
> mean by this is that if there is 10 seconds of time between event "a"
> and event "b", and 5 seconds of time between event "b" and event "c",
> then we will see event "a", a large gap, event "b", a smaller gap, event
> "c".
>
> This seems natural, however when debugging for the most part we don't
> really care how much time is between each pair of events, we just want
> to know that event "a" happened, then event "b" then event "c". (or "c"
> then "b" and we see the race condition that we were looking for for
> example.)
>
> So is anybody really set on having realistic time differences between
> events or can I start switching it over to have a set amount of space
> between each event. I don't want events to overlap, so if an event
> happens then each trace will move forward one space to decide where to
> put an event.
>
> So previously if thread A forked, then waited 10 seconds, then thread B
> cloned, wait 5 seconds,  and thread A exited we would see:
>
> Thread A -------[]-------------*
> Thread B--------------------()---
>
> I propose:
>
> Thread A -----[]-----------*
> Thread B -----------()-----
>
> Any thoughts?
>
>

Attachment: signature.asc
Description: OpenPGP digital signature