bt2 python - accessing component instances added to graph

bt2 python - accessing component instances added to graph

[Rocky Dunlap via lttng-dev]

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

I noticed that when I add a component to a bt2 graph, e.g.:

sink = g.add_component(SinglePETSink, "sink"+str(idx))

The return value "sink" is not actually an instance of SinglePETSink (which
has been defined as a local Python class).  How do I get to the instance of
SinglePETSink that was created?

Rocky

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

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

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: bt2 python - accessing component instances added to graph

[Simon Marchi via lttng-dev]

On 2020-03-30 1:24 a.m., Rocky Dunlap via lttng-dev wrote:
> I noticed that when I add a component to a bt2 graph, e.g.:
> 
> sink = g.add_component(SinglePETSink, "sink"+str(idx))
> 
> The return value "sink" is not actually an instance of SinglePETSink (which has been defined as a local Python class).  How do I get to the instance of SinglePETSink that was created?

If I understand your question correctly: this is actually on purpose to preserve
encapsulation of each component: the user of the graph has the control on the
component when creating it, it can pass parameters to it.  But after that, it
should not be able to go play with the internals of the component.  The `self`
object that has access to the component's state is only available when the
component's methods are called.

So when the user of the graph adds a component, it only receives a generic
component object, which can only be used to access public properties (including
a public view of its ports, that you can use to connect them).

Of course, you can always get around this with a global variable, doing like
this in the component's init:

  global my_component
  my_component = self

But hopefully you won't need to.  If you explain what you are trying to achieve,
we can see if there's a proper way to do it using the existing API.

Simon
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: bt2 python - accessing component instances added to graph

[Rocky Dunlap via lttng-dev]

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

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

Simon,

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

Rocky

On Mon, Mar 30, 2020 at 2:38 PM Simon Marchi <simark@simark.ca> 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:
>
>
> https://github.com/efficios/babeltrace/blob/8b305066676fc7aa433e8eb668f9de8802008025/tests/bindings/python/bt2/test_graph.py#L106-L120
>
> 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
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev