archive mirror
 help / color / mirror / Atom feed
From: Rocky Dunlap via lttng-dev <>
To: Simon Marchi <>
Subject: Re: bt2 python - accessing component instances added to graph
Date: Mon, 30 Mar 2020 14:41:00 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1.1: Type: text/plain, Size: 2166 bytes --]

(Adding the list back in - I meant to reply-all before...)


Yes, the obj solution should work just fine - I was wondering about that
parameter and the approach makes sense to me.  Thanks!


On Mon, Mar 30, 2020 at 2:38 PM Simon Marchi <> wrote:

> On 2020-03-30 4:24 p.m., Rocky Dunlap wrote:
> > Simon,
> >
> > In my case, after the graph completes, I was trying to access the sink
> instances in order to collect some statistics collected inside the instance
> during the graph run.  I guess then the question is how are the graph
> components supposed to communicate with the outside world in general, such
> as filling in some Python data structures with info from a trace for
> post-processing or further analysis in Python?  Or is the expectation that
> sink components will retain no state at all after the graph completes?
> >
> > Rocky
> Hi Rocky,
> Was it your intention to not do a reply-all?  I think this would be good
> info for all to read.  If not,
> please do a reply-all and I'll replay again what I wrote below on the list.
> Of course the sinks are expected to produce some result outside of their
> own little internal state.  For
> sinks that produce some trace files, they'll typically write on the
> filsystem (like sink.ctf.fs).
> But if you want to send some results to another Python object/data
> structure, the `obj` parameter of
> `add_component` is pretty much meant for that.  You can pass in a
> reference to a Python object, and
> the component receives it in its `__init__`.  We thought that this could
> be useful, for example, if
> the sink needs to receive a connection handle to a database, for example.
> That handle can be created
> outside of the sink and passed it when instantiating the component.  Think
> of it like some void* user
> data in C.
> In your case, you could create whatever object you need to collect your
> statistics/results, and pass
> a reference to it.
> Here's an example in the tests:
> Does that help?
> Simon

[-- Attachment #1.2: Type: text/html, Size: 2808 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

lttng-dev mailing list

      parent reply	other threads:[~2020-03-30 20:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30  5:24 Rocky Dunlap via lttng-dev
2020-03-30 13:45 ` Simon Marchi via lttng-dev
     [not found]   ` <>
     [not found]     ` <>
2020-03-30 20:41       ` Rocky Dunlap via lttng-dev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \
    --subject='Re: bt2 python - accessing component instances added to graph' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).