Sorry about the unclear code, that was just a consequence of simplifying down from the actual use-case, however, to me it seems not to be the same thing.
In your example you have one struct and capture a method on that same struct twice, refering to the same - that makes sense. However, in my example I have two different structs, capturing the method on the two different ones (lines 35, 37), they then operate independently (as expected) but they have the same adr (line 72)? thanks for you help though :-) On Saturday, December 9, 2017 at 2:33:48 PM UTC+1, Jakob Borg wrote: > > I confess I find the code a bit convoluted and hard to follow - but > doesn’t it just boil down to method values bound to the same pointer, thus > acting on the same struct value (state)? > > https://play.golang.org/p/VVdSyaYp5x > <https://play.golang.org/p/FjP0FXTqTS> > > //jb > > > On 9 Dec 2017, at 09:23, viktor...@gmail.com <javascript:> wrote: > > Hi, > > > I have a problem that I have tried to reduce to a minimal re-producible > example, I have not fully managed but it does show some to me strange > behavior: > > > https://play.golang.org/p/ZCyumUPBos > > > I have a similar set up in a much larger set-up where I seem to see (no > errors reported by race-detector) that sometimes inside a "actionWithState" > the state is not remembered correctly/shared with other instances of > "actionState"s. In this playground example however it always seems to > behave as intended with each actionState's action method using its own > state. In the example above however (I see the same thing) both actions *have > the same address* when printed, how can that be that they behave > differently if they point to the same data? > > > I.e. I have two questions where I would appreciate tips since I cannot > seem to wrap my head around it: > > 1. How can (in this code) actions[1] and actions[2] contain the same > pointers (as seen by fmt.Print) yet behave differently when called as > functions? > > 2. Although the behavior of the example above is what I expected (apart > from it printing the same pointer value), is there any circumstance under > which they would start to "share state" which I have not thought of that > could lead to the problem I am seeing in my larger code-base that you could > think of? > > > Any thoughts appreciated :-) > > > > -- > 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...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > -- 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.
