goroutine id
Andrew Deane
A while back there was a discussion concerning the id of a goroutine.
Did this get resolved? Is the id of a goroutine available at run time?
I have an application that spins up lots of goroutines and
subsequently the log file is noisy. It would be nice to see the origin
of the messages for support.
Thanks.
Russ Cox
No. This almost always leads to bad programs
that try to do things like per-goroutine state.
There's already the stack for that.
> I have an application that spins up lots of goroutines and
> subsequently the log file is noisy. It would be nice to see the origin
> of the messages for support.
You could print the origin. Passing it in explicitly
means each goroutine can describe itself with a
real string instead of an arbitrary number.
Russ
⚛
> > Is the id of a goroutine available at run time?
>
> No. This almost always leads to bad programs
> that try to do things like per-goroutine state.
> There's already the stack for that.
- You cannot give a name to a stack item and use that name freely as a
per-goroutine variable
- If per-goroutine state is a bad thing, wouldn't that automatically
imply that per-process state is a bad thing as well?
Jesper Louis Andersen
> On Oct 20, 5:15 pm, Russ Cox <r...@golang.org> wrote:
>> > Is the id of a goroutine available at run time?
>>
>> No. This almost always leads to bad programs
>> that try to do things like per-goroutine state.
>> There's already the stack for that.
>
> - Stack is not the same thing as random-access linear memory
In my opinion, it is very close to RAM. If you have a pointer to the
memory on the stack and you are the sole owner of that pointer, it
looks to me as being equal to thread-local data. Alternatively, since
Go has closures, you can wrap up the state in a closure and
essentially get a pointer to it that way. From my experience, it is
often the case that this is enough to implement most things where you
would want access to linear memory. (Note, we may talk past each other
here and debate two entirely different things while we both think the
understanding "I" have is the understanding of both).
[notice I am replying to Russ here:]
>>
>> You could print the origin. Passing it in explicitly
>> means each goroutine can describe itself with a
>> real string instead of an arbitrary number.
>>
I think this is the way to go - from experience in Haskell and Erlang.
A goroutine is there for a reason, to solve a specific task. If it is
"singleton" it has some global name, a string if you will, that
identifies the process. If there is more than one goroutine executing
the same code, they tend to have another unique component which
discriminates them from each other. A way to identify a process by a
given name in a log output is indeed a nice thing. But my experience
tells me that one should beware using such names as a programmatic
construct. The goroutine might end and the name is now lingering.
Unless you have other means to clean up, this will become a problem.
In Go, identity and capability is ultimately tied to a channel, not a
process. Channels are the thing you give a name, so you can later
identify it. It is not going away as long as somebody holds a
reference to it. If I understand the idioms correctly, you should be
using channels to discriminate a set of goroutines, programmatically,
rather than an eventual PID.
--
J.
Russ Cox
that happens today in C, where libraries squirrel
away data in per-thread storage and then have APIs
like "after calling f in one thread, all future calls
to g, and h must be made in that same thread."
> - If per-goroutine state is a bad thing, wouldn't that automatically
> imply that per-process state is a bad thing as well?
No, because we're talking about state inside a
Go program, and a Go program is only ever one process.
Russ
Andrew Deane
calling code identifies itself to the messaging lib.
Thanks all.
Jonathan
processes; a thread shares state with other threads. Adding per-
thread state increases (geometrically?) the possible complexity of the
program state. Increased complexity of the program state leads to
programs that are hard to debug and test.
A lot of bad threaded programs are written as though threads were
processes and end up breaking when they treat shared state as
unshared. The libraries Russ dislikes are encouraging this view of
thread as processes.
As far as logging goes, my experience is that debugging from a log
with meaningless thread ids will give you a headache in no time at
all. You are better off naming them yourself anyway.
Jonathan