On Fri, Jun 15, 2018 at 2:20 AM, <
ala...@dotmesh.com> wrote:
>
> I agree the OP possibly doesn't want thread-local storage (although I'd like
> to point out that Scheme's dynamically-scoped "parameters" are a great way
> to do what the OP wants!), but I'll post another use case where thread IDs
> of some kind are useful: I work on highly concurrent software, and it's very
> useful to be able to dump all the goroutines in such a system and see what
> they're doing. Sure, we've got the pprof goroutine profile, but that gives
> limited information - I have many goroutines using a polling function that
> calls a func, then sleeps, then loops forever. So, in most goroutine
> profiles, I see that goroutine in a sleep rather than in its polling
> function, and so can't tell what the purpose of that goroutine is (despite
> it having a string named in its stack frame, used when printing an error
> returned from the func). It'd be nice if I could record a mapping from the
> "goroutine ID" of these, and similar, goroutines to arbitrary "what this
> goroutine is for" strings that I could look up in my dump. In Java, every
> thread has a name field, which I (ab)used for this purpose to great effect!