Re: [go-nuts] Unexpected pointer dereference behavior

2021-04-22 Thread 'Axel Wagner' via golang-nuts
On Fri, Apr 23, 2021 at 1:36 AM Nail Islamov wrote: > Answers above don't explain the difference in behavior: > [1] https://play.golang.org/p/lXA2F4b880W > [2] https://play.golang.org/p/doruBxrquhw > > Why did deadlock happen in [1], despite creating a variable? > If I change the order ([2]), I d

Re: [go-nuts] Unexpected pointer dereference behavior

2021-04-22 Thread Nail Islamov
Sorry, ignore that. In [1], I make a copy of a locked mutex, which creates a *new *locked mutex. Basically the only non-obvious behavior here is that `&(*m) == m` by the rules of Go, the rest was explained above. On Friday, 23 April 2021 at 9:36:26 am UTC+10 Nail Islamov wrote: > Answers above

Re: [go-nuts] Unexpected pointer dereference behavior

2021-04-22 Thread Nail Islamov
Answers above don't explain the difference in behavior: [1] https://play.golang.org/p/lXA2F4b880W [2] https://play.golang.org/p/doruBxrquhw Why did deadlock happen in [1], despite creating a variable? If I change the order ([2]), I do avoid a deadlock (meaning that I have two separate mutexes).

Re: [go-nuts] Unexpected pointer dereference behavior

2021-04-22 Thread 'Axel Wagner' via golang-nuts
I think what is going on here is that it is wrong to say that `(*observer)` creates a copy: https://golang.org/ref/spec#Address_operators > For an operand x of pointer type *T, the pointer indirection *x denotes > the variable of type T pointed to by x. That variable is addressable and contains

Re: [go-nuts] Unexpected pointer dereference behavior

2021-04-22 Thread Jan Mercl
On Thu, Apr 22, 2021 at 1:39 PM Mikhail Mazurskiy wrote: > Thanks for the response, I didn't see this section. However, I'm still > confused as it says the exception in 3. only applies to fields, not to > methods. RLock() is obviously a method, not a field. You're right. And because the playgr

Re: [go-nuts] Unexpected pointer dereference behavior

2021-04-22 Thread Mikhail Mazurskiy
On Thu, 22 Apr 2021 at 21:27, Jan Mercl <0xj...@gmail.com> wrote: > On Thu, Apr 22, 2021 at 1:15 PM Mikhail Mazurskiy > wrote: > > > I stumbled upon this strange looking piece of code [1]. I thought it > dereferences the pointer, creating a copy of the mutex, and then calls > RLock() on the copy

Re: [go-nuts] Unexpected pointer dereference behavior

2021-04-22 Thread Jan Mercl
On Thu, Apr 22, 2021 at 1:15 PM Mikhail Mazurskiy wrote: > I stumbled upon this strange looking piece of code [1]. I thought it > dereferences the pointer, creating a copy of the mutex, and then calls > RLock() on the copy (i.e. a nop). But it does not work this way. I > experimented with it [