[go-nuts] Re: Panic recovery and mutex lock question

2017-10-19 Thread Tamás Gulácsi
Quote from the language reference: "A "defer" statement invokes a function whose execution is deferred to the moment the surrounding function returns, either because the surrounding function executed a return statement, reached the end of its function body, or because the corresponding goroutine

[go-nuts] Re: Panic recovery and mutex lock question

2017-10-19 Thread David Renne
OK I think I have my questions answered, I think the moral is dont intermix or add code above your lock if you are worried about any panics calling it before, this way you know that you are in a lock right when the function hits it and can always defer the unlock until after. I suppose in some

Re: [go-nuts] Re: Panic recovery and mutex lock question

2017-10-18 Thread Ian Lance Taylor
On Wed, Oct 18, 2017 at 7:46 AM, David Renne wrote: > > I guess I was wondering still if we had existing code with multiple mutexes > being locked or rLocked where we didnt have the defer unlocks and those > panic. > > I guess I dont understand why you would want the lock entirely for the > entire

[go-nuts] Re: Panic recovery and mutex lock question

2017-10-18 Thread Juliusz Chroboczek
> I guess I dont understand why you would want the lock entirely for the > entire execution of the function until the defer. You can get the effect of block-scoped defers by using a local anonymous function: func f(a *A) { func() { a.mu.Lock() defer a.mu.Lock(

[go-nuts] Re: Panic recovery and mutex lock question

2017-10-18 Thread David Renne
Thank you Ian. I guess I was wondering still if we had existing code with multiple mutexes being locked or rLocked where we didnt have the defer unlocks and those panic. I guess I dont understand why you would want the lock entirely for the entire execution of the function until the defer. It