On Saturday, September 26, 2020 at 12:34:37 PM UTC-7 Ian Lance Taylor wrote:
> > A Go-style goroutine-local system can be thought as a context.Context
> that is transparently assigned to a goroutine and its children. Thus if you
> want to change the value, you'd do something like "c :=
>
On Saturday, September 26, 2020 at 12:33:40 PM UTC-7 Ian Lance Taylor wrote:
> On Fri, Sep 25, 2020 at 6:29 PM Alex Besogonov
> wrote:
> > If you mutate the value, then only the current goroutine is affected
> (not even its existing children). Basically, the goroutine-local context is
>
On Saturday, September 26, 2020 at 5:41:54 AM UTC-7 rog wrote:
> A Go-style goroutine-local system can be thought as a context.Context that
>> is transparently assigned to a goroutine and its children. Thus if you want
>> to change the value, you'd do something like "c :=
>>
On Fri, Sep 25, 2020 at 6:36 PM Alex Besogonov wrote:
>
> On Friday, September 25, 2020 at 4:43:45 PM UTC-7 Ian Lance Taylor wrote:
>>
>> On Fri, Sep 25, 2020 at 10:35 AM Alex Besogonov
>> wrote:
>> >
>> > Inheritable goroutine-locals would actually work just fine in Go.
>> > Moreover, Go
On Fri, Sep 25, 2020 at 6:29 PM Alex Besogonov wrote:
>
> If you mutate the value, then only the current goroutine is affected (not
> even its existing children). Basically, the goroutine-local context is copied
> on new goroutine launch.
>
> That's how pprof labels work right now, btw.
Labels
On Sat, 26 Sep 2020, 02:36 Alex Besogonov, wrote:
> On Friday, September 25, 2020 at 4:43:45 PM UTC-7 Ian Lance Taylor wrote:
>
>> On Fri, Sep 25, 2020 at 10:35 AM Alex Besogonov
>> wrote:
>> >
>> > Inheritable goroutine-locals would actually work just fine in Go.
>> Moreover, Go actually has
On Friday, September 25, 2020 at 4:43:45 PM UTC-7 Ian Lance Taylor wrote:
> On Fri, Sep 25, 2020 at 10:35 AM Alex Besogonov
> wrote:
> >
> > Inheritable goroutine-locals would actually work just fine in Go.
> Moreover, Go actually has them in the form of pprof labels.
> What should happen
If you mutate the value, then only the current goroutine is affected (not
even its existing children). Basically, the goroutine-local context is
copied on new goroutine launch.
That's how pprof labels work right now, btw.
On Friday, September 25, 2020 at 4:43:45 PM UTC-7 Ian Lance Taylor
On Fri, Sep 25, 2020 at 10:35 AM Alex Besogonov
wrote:
>
> Inheritable goroutine-locals would actually work just fine in Go. Moreover,
> Go actually has them in the form of pprof labels.
What should happen if one goroutine changes an inherited
goroutine-local variable?
Ian
> On Wednesday,
Inheritable goroutine-locals would actually work just fine in Go. Moreover,
Go actually has them in the form of pprof labels.
On Wednesday, September 23, 2020 at 5:55:50 PM UTC-7 Ian Lance Taylor wrote:
> On Wed, Sep 23, 2020 at 5:46 PM Alex Mills wrote:
> >
> > There appears to be a way to
On Wed, Sep 23, 2020 at 6:02 PM Alex Mills wrote:
>
> Not a joke, in terms of performance, if you access the goroutine id via the C
> library call?
I'm not sure what C library call you mean.
> My only concern would be if goroutine id's were reused, if not it would work.
Goroutine IDs are not
On Wed, 2020-09-23 at 18:12 -0700, Alex Mills wrote:
> But I tried compiling this program:
> https://github.com/davecheney/junk/tree/master/id
>
> and I cant get it to compile/run, the runtime.h file seems MIA
>
> -alex
There is this: https://github.com/kortschak/goroutine
Don't use it; do
But I tried compiling this program:
https://github.com/davecheney/junk/tree/master/id
and I cant get it to compile/run, the runtime.h file seems MIA
-alex
On Wed, Sep 23, 2020 at 6:02 PM Alex Mills wrote:
> Not a joke, in terms of performance, if you access the goroutine id via
> the C
Not a joke, in terms of performance, if you access the goroutine id via the
C library call?
My only concern would be if goroutine id's were reused, if not it would
work.
On Wed, Sep 23, 2020 at 5:54 PM Ian Lance Taylor wrote:
> On Wed, Sep 23, 2020 at 5:46 PM Alex Mills wrote:
> >
> > There
On Wed, Sep 23, 2020 at 5:46 PM Alex Mills wrote:
>
> There appears to be a way to get a reference on the goroutine id:
>
> http://blog.sgmansfield.com/2015/12/goroutine-ids/
But as you can see by reading that blog article, that is almost a joke.
Go considers these things to be better handled
Not sure about that. Context can store a map. I could map:
request => userid
but then I would have to pass the request to the logging statements, so
that would put me back at square one.
There appears to be a way to get a reference on the goroutine id:
On Wed, Sep 23, 2020 at 6:17 PM Alex Mills wrote:
>
> Since by default all http requests coming to a go http server are on their
> own goroutine, I am wondering if there is a way to have some sort of "global"
> variable that is local to a goroutine if that makes sense, something like
> this,
As far as I know, that is exactly what the Context package and customs are
meant for.
[Joop Kiefte - Chat @
Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=p4aw3)
[p4aw3]
On September 24, 2020 at 0:17 GMT, Alex Mills wrote:
Since by default all http requests coming to a
Since by default all http requests coming to a go http server are on their
own goroutine, I am wondering if there is a way to have some sort of
"global" variable that is *local* to a goroutine if that makes sense,
something like this, where "gork" is the namespace for variables available
19 matches
Mail list logo
