You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I am considering using the library, however, I am spotting some design choices that I do not understand regarding the open/close packet.
As I understand the packets are closed by the function when the barectf engine is call the callbacks. I understand why you let the user call the function that actually closes the stream's packet.
However, I do not understand why would you use a stream's specific function ( e.g barectf_my_stream_close_packet) rather than a generic function to allow an easy re-usability (e.g close_stream_packet(ctx)). The context holds all the information necessary for this to be possible.
And even better. To allow the same trace to share the callbacks, why not create a barectf ctx and attach all the different streams to it? So we could gain even more re-usability.
The text was updated successfully, but these errors were encountered:
In the generated barectf.c file, the packet closing functions are different, that is:
barectf_A_close_packet() gets a value from the user-defined clock value callback and needs the cur_last_event_ts and off_pc_timestamp_end fields of struct barectf_A_ctx (both don't exist in struct barectf_B_ctx).
barectf_A_close_packet() also needs the off_pc_events_discarded field of struct barectf_A_ctx to know where to write the discarded event record counter snapshot value within the packet context.
Therefore you need to call barectf_A_close_packet() when closing a packet of a data stream of type A and barectf_B_close_packet() when closing a packet of a data stream of type B.
For two data stream types having a default clock type and the exact same features, however, I get your point: barectf could generate a single pair of opening/closing functions for them. Maybe we could define a named class of data stream types in the configuration and link data stream types to this class. Something like this. The tool is just not there yet!
Hi,
I am considering using the library, however, I am spotting some design choices that I do not understand regarding the open/close packet.
As I understand the packets are closed by the function when the barectf engine is call the callbacks. I understand why you let the user call the function that actually closes the stream's packet.
However, I do not understand why would you use a stream's specific function ( e.g barectf_my_stream_close_packet) rather than a generic function to allow an easy re-usability (e.g close_stream_packet(ctx)). The context holds all the information necessary for this to be possible.
And even better. To allow the same trace to share the callbacks, why not create a barectf ctx and attach all the different streams to it? So we could gain even more re-usability.
The text was updated successfully, but these errors were encountered: