Hi Yann,
Am 27.04.2020 um 16:40 schrieb Yann Ylavic:
Hi Rainer,
On Mon, Apr 27, 2020 at 3:17 PM Rainer Jung <[email protected]> wrote:
Thanks for this.
Could you please create this as a PR on github as well? This ensures that all
the Travis tests are run for your patch.
Thanks Rüdiger. Done and indeed Travis found one not that I fixed but we
need to discuss.
Thanks Rainer, looks very nice.
Could we avoid the "ap_sload_t *sload" pointer in ap_mon_snap_t somehow?
I'm asking because snap0 and snap1 in global_score (SHM) end up
containing a pointer now.
My initial version had the fields of ap_sload_t directly inside
ap_mon_snap_t instead of the pointer.
I changed it, because
- it allowed to more safely copy the whole ap_sload_t without relying on
keeping two struct definitions in sync
- it allowed to extend ap_sload_t and ap_mon_snap_t at their respective
ends and stay compatible.
You have a problem with the pointers because of possible alignment
issues or what kind of trouble might we run into? Or is it just hard to
understand (and more comments in the code will help)?
Or because it is harder for consumers to use the API in a correct way
(the pointer in ap_mon_snap_t might be uninitialized)? In the latter
case: one could also see this as a feature instead of as a bug: as long
as one is only interested in the averaged data and not in the sload
data, you can pass in an ap_mon_snap_t with a null pointer to the
ap_sload_t.
Regards,
Rainer
