Now i have the same problem as you, i need to record log id through a web
request, and pass the log id by httpContext, its look orderless for my
code, so sad!
On Thursday, February 25, 2016 at 1:59:11 AM UTC+8, Damian Turczyński wrote:
>
> Kevin
>
> I have in my opinion valid reason. I'm writing a web server in go. I want
> to have logs across all application to include requestID. The only way I
> can do that is to pass httpContext everywhere! Which is hilarious, and
> super unclean. In other languages/frameworks it is possible as you have
> something like HttpContext accessible globally, and yet of course you have
> to deal with spawning child threads with care and maybe even to pass
> httpContext there but it's much smaller hustle than passing httpContext in
> every single function I'll write in my application.
>
> On Sunday, October 14, 2012 at 1:36:25 PM UTC+1, Kevin Gillette wrote:
>>
>> That should be fine, but in this case, it'd be better to refer to it as
>> 'task specific' instead of 'goroutine local', since your struct
>> isn't/shouldn't be designed around the assumption that it's goroutine local.
>>
>> The big issue with stuff not being freed is when a map of goroutine id to
>> data is used (if the goroutine exits without deleting its data from the
>> map, a leak has occurred), not to mention that there are _extremely_ few,
>> if any (I'm strongly edging towards there being none) legitimate reasons to
>> store data based on goroutine Id -- that kind of thinking is generally a
>> carryover for languages that are much less effective at handling
>> concurrency.
>>
>> On Saturday, October 13, 2012 9:12:40 AM UTC-6, bryanturley wrote:
>>>
>>>
>>> On Sat, Oct 13, 2012 at 8:54 AM, bryanturley <bryan...@gmail.com> wrote:
>>>>
>>>>> What I do when i need something like this is
>>>>>
>>>>> type LilSrv struct {
>>>>> // bleh
>>>>> // your goroutine local stuff here nicely predefined
>>>>> // some chans to talk to it
>>>>> }
>>>>>
>>>>> func (ls *LilSrv) MLoop() {
>>>>> for {
>>>>> // bleh, stuff
>>>>> }
>>>>> }
>>>>>
>>>>> ... somewhere in your code
>>>>>
>>>>> ls = new(LilSrv) // or similar
>>>>> go ls.MLoop() // normally i have this wrapped in something like
>>>>> "NewLilSrv() (ls *LilSrv)"
>>>>>
>>>>> now that ls is your goroutine local storage without using c code or
>>>>> any other way to low level for normal use code.
>>>>>
>>>>>
>>> Are you saying the ls in my example won't get GC'ed when it isn't in use
>>> anymore?
>>> What I exampled here is done throughout the standard library... for
>>> instance inside
>>> http://golang.org/src/pkg/net/http/server.go?s=30567:30613#L1015
>>> c, e := newConn() few lines later
>>> go c.serve()
>>> I think my phrasing just confused you.
>>> The entire idea of this was to make it not a global state, just a struct
>>> that got allocated before the goroutine started that was explicit to that
>>> goroutine and others that need to talk to it.
>>> And if a new goroutine is started in ls.MLoop it doesn't necessarily
>>> even matter if it can see that ls.
>>>
>>> The real problem was a single global name that lived in a new spot
>>> automagically each thread, that is clearly not happening here.
>>>
>>>
On Thursday, February 25, 2016 at 1:59:11 AM UTC+8, Damian Turczyński wrote:
>
> Kevin
>
> I have in my opinion valid reason. I'm writing a web server in go. I want
> to have logs across all application to include requestID. The only way I
> can do that is to pass httpContext everywhere! Which is hilarious, and
> super unclean. In other languages/frameworks it is possible as you have
> something like HttpContext accessible globally, and yet of course you have
> to deal with spawning child threads with care and maybe even to pass
> httpContext there but it's much smaller hustle than passing httpContext in
> every single function I'll write in my application.
>
> On Sunday, October 14, 2012 at 1:36:25 PM UTC+1, Kevin Gillette wrote:
>>
>> That should be fine, but in this case, it'd be better to refer to it as
>> 'task specific' instead of 'goroutine local', since your struct
>> isn't/shouldn't be designed around the assumption that it's goroutine local.
>>
>> The big issue with stuff not being freed is when a map of goroutine id to
>> data is used (if the goroutine exits without deleting its data from the
>> map, a leak has occurred), not to mention that there are _extremely_ few,
>> if any (I'm strongly edging towards there being none) legitimate reasons to
>> store data based on goroutine Id -- that kind of thinking is generally a
>> carryover for languages that are much less effective at handling
>> concurrency.
>>
>> On Saturday, October 13, 2012 9:12:40 AM UTC-6, bryanturley wrote:
>>>
>>>
>>> On Sat, Oct 13, 2012 at 8:54 AM, bryanturley <bryan...@gmail.com> wrote:
>>>>
>>>>> What I do when i need something like this is
>>>>>
>>>>> type LilSrv struct {
>>>>> // bleh
>>>>> // your goroutine local stuff here nicely predefined
>>>>> // some chans to talk to it
>>>>> }
>>>>>
>>>>> func (ls *LilSrv) MLoop() {
>>>>> for {
>>>>> // bleh, stuff
>>>>> }
>>>>> }
>>>>>
>>>>> ... somewhere in your code
>>>>>
>>>>> ls = new(LilSrv) // or similar
>>>>> go ls.MLoop() // normally i have this wrapped in something like
>>>>> "NewLilSrv() (ls *LilSrv)"
>>>>>
>>>>> now that ls is your goroutine local storage without using c code or
>>>>> any other way to low level for normal use code.
>>>>>
>>>>>
>>> Are you saying the ls in my example won't get GC'ed when it isn't in use
>>> anymore?
>>> What I exampled here is done throughout the standard library... for
>>> instance inside
>>> http://golang.org/src/pkg/net/http/server.go?s=30567:30613#L1015
>>> c, e := newConn() few lines later
>>> go c.serve()
>>> I think my phrasing just confused you.
>>> The entire idea of this was to make it not a global state, just a struct
>>> that got allocated before the goroutine started that was explicit to that
>>> goroutine and others that need to talk to it.
>>> And if a new goroutine is started in ls.MLoop it doesn't necessarily
>>> even matter if it can see that ls.
>>>
>>> The real problem was a single global name that lived in a new spot
>>> automagically each thread, that is clearly not happening here.
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
