Hi Josef, thanks for your explanation.
On Thu, 21 Jul 2016 12:16:28 +0200 Josef Söntgen <[email protected]> wrote: > Hello Johannes, > > * Johannes Schlatow <[email protected]> [2016-07-20 16:49:12 +0200]: > > The documentation suggests that the trace buffer is assigned to a > > thread. On the other hand, the trace subject is associated with a > > session label. What I conclude from this is that a thread be > > identified by multiple trace subjects but can only be assigned a > > single trace policy and trace buffer, which makes the interface quite > > confusing. > > A Trace::Subject *may* contain a attached Trace::Buffer and at some > point *did* contain a Trace::Source. To enable tracing the Subject > must have a valid Trace::Policy that in return is used by the Source > to fill the Trace::Buffer. A Subject can only be part of one Session. > Subjects that belong to another Session have the state FOREIGN (see > [1]). > > [1] repos/base/include/base/trace/types.h > > > I also had a glance at the implementation and noticed that the > > Trace::Subject has its own buffer, which is forwarded to the > > Trace::Source. If I understand this correctly, the Trace::Source is > > coupled to a thread. I therefore assume that I can only trace one > > trace subject (associated with the same thread) at a time. Is this > > correct? > > You can trace as many subjects as your resources permit within a single > Trace::Session. The Subject outlives the Source (that is why it forwards > the Buffer to the Source) so one can process the content even after the > Source has vanished. As you have noticed a Trace::Source is coupled to > Thread and so is a Subject to its Source. That is a Subject does not get > reused. After tracing has been enabled for a given Subject it will “live” > and consum memory as long as it is not freed by the Session, even when > its Source has vanished. New Subjects will be created in a lazy fashion > whenever Trace::Session::subjects() is called (see [2]) and there are > new Sources. Untraced Subjects will vanishes when its Source vanishes. > > [2] repos/base/src/core/trace_session_component.cc > > So from a user perspective or rather from the point of view of a > Trace-monitor (the component managing the Trace::Session) all you care > about is a Trace::Subject. To fill the Trace::Buffer, i.e. create > entries, you care about the Source which is a Thread. That is why the > methods for creating entries is part of the Thread API. Okay. I think I got confused by the session label. For a moment I assumed these corresponded to the service provided by the traced component but it's actually the label of the component's CPU session, which makes much more sense now ;-) Anyway, I have a much better understanding of the implementation now. Cheers Johannes ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ genode-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/genode-main
