Alastair Robertson

Maybe #3126 is the solution for this bug as well? When reading a per-cpu map value, collect data from all CPUs.

How about `VERBOSE` instead of `V1` if we're only having one verbosity level? > * `ERROR`: log info to indicate that the user did something invalid which will (eventually) cause...

I think it'd also be fine to require use of the `retval` builtin and not allow `args.retval` to be used - it's just the inconsistencies between listing/field accesses/printing that need...

> Maybe we could add an `aprint()` alias for the old behavior? And `print()` gets sync by default. I imagine this is beneficial for nearly everyone while also giving pathological...

@janet-campbell Maybe we're talking about different types of "asynchronous printing" here. `print` and `printf` in bpftrace are asynchronous functions, in that calling them just involves putting data onto a ring...

> I'm leaning toward @danobi's suggestion of adding an async print builtin. It's more explicit and removes the need for map copying. Why not the explicit map references approach (https://github.com/bpftrace/bpftrace/issues/3028#issuecomment-2010250450)?...

> Do you mind sharing your thought process behind preferring syntax extensions over functions? IMO functions are strongly typed and have clear bounds on interaction w/ other parts of the...

Just reposting from the above linked issue to consolidate discussion in this thread: Named function arguments as an alternative way of handling synchronous vs asynchronous map printing: ``` print(@mymap); //...

Yeah, giving existing positional parameters names sounds good to me. On first impression, I'd prefer to not allow `async` as an unnamed argument. - `print()` already takes a couple of...

Reopening as this doesn't appear to have been implemented