Prepend "thread (%d)" to output from jl_print_task_backtraces()

[kpamnany]

PR Description

More backtrace prepending, this time to the text output by jl_print_task_backtraces().

This should be squashed with the following commits when we upgrade:

• 0457f8995eb49158adcab9b12d21d9d31e9e05d4
• e015382634953445155c9fa4f51aba05235e8313
• 8f409da5c564d8fd9e9a2d0fe19235a710fedd09

Checklist

Requirements for merging:

• I have opened an issue or PR upstream on JuliaLang/julia: Stack traces can be interleaved when running multithreaded JuliaLang/julia#51056
• I have removed the port-to-* labels that don't apply.
• I have opened a PR on raicode to test these changes: https://github.com/RelationalAI/raicode/pull/15869

[NHDaly]

Can you explain the idea behind this one? Is the new jl_task_backtraces printing multithreaded? I don't see any discussion of this in the issue you link to in the PR description: JuliaLang#51056.

[NHDaly]

Or is it because you're now triggering this asynchronously, according to some conditions, and there's a chance that two threads would trigger it at the same time?

EDIT: If it's the latter, i think maybe a better solution would be to add an optional parameter for an IO object to write this output to. That way we can write each one to a buffer, and then dump the whole thing in one nice message to datadog?

(I think if you log a json line to datadog, it will make it all in one log message, rather than splitting it up. So you could print it like this:

data = String(take!(io)) # or whatever
println("""{"message":$(repr(data))}""")

and then it would be formatted much more nicely in datadog.

[NHDaly]

👍 The implementation here LGTM but i'm not sure i understand the purpose.

[kpamnany]

I should have explained better.

Or is it because you're now triggering this asynchronously, according to some conditions, and there's a chance that two threads would trigger it at the same time?

Because we're triggering this asynchronously, other threads are still running and could be logging things, which could result in other log messages interleaving with the backtraces. The approach we chose to address this interleaving problem was adding these prefixes. The individual task backtraces are already prefixed with thread (%d); this just adds the same prefixes to the other informational lines printed. Although there won't be much ambiguity caused by these interleavings, it just makes it a bit cleaner?

As this is in C code, using an IOBuffer would be difficult.

[NHDaly]

Mmm yeah, you're right, i forgot about that. The C code can write to file pointers just fine, but not IOBuffers. :/
We could use a temporary file for this still though.

---

But okay cool thanks yeah that explanation makes sense.