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

[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 is panicking."

So, a deferred function will be called in case of panic, too.
No need to unlock in the panic handler!

-- 
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.

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

[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 
really bad code with a panic handler someone could accidentally throw a 
panic deeper down in a function and since that code was above the Lock the 
panic handler wouldnt know whether its open or not.  I just wish sometimes 
we could know whether a lock is open or not on a given sync.RWMutex as a 
public variable.  Oh well... 

I really like some of Juliusz's examples to separate out the locks with 
anonymous functions because it keeps the logic safer from anyone adding 
code or function calls that can be more dangerous for things like panic 
handlers.  

Thanks everyone, I think I am good on this question and my brother solved 
some of our web socket lock issues in our code dealing with websockets.

https://github.com/DanielRenne/GoCore/commit/1a6418c2734f985955571ff6015f8d82736890ae

I still get scared any minute a client websocket or some unhandled thing 
might cause a lock, but only time will tell.  Node.js websockets are easy 
because theres only one thread!

If anyone feels like reviewing master of this project and helping us find 
some potential bad code, we need some golang experts to review any lock 
practices we can improve on problems before they become problems and 
refactor any bad code out.  Sometimes I wish we found this melody library 
which handles all the locking for websockets with 
gorilla package.  https://github.com/olahol/melody  Oh well.  That package 
might not even work for our use case anyway.

I removed some unlocks he put in on the recovery because the second defer 
will always be called regardless of panic right?  There is no way 
golang will skip any deferred on a panic for any reason right?

https://github.com/DanielRenne/GoCore/commit/9685fb3f6fabe612e005238119349144da3bba18

Thanks for listening to my rants everyone!  If anyone explores some of our 
bad code and wants to help us just reply here or email me direct from 
github https://github.com/davidrenne/

On Tuesday, October 17, 2017 at 8:15:23 PM UTC-4, David Renne wrote:
>
> Hi there,
>
> I was wondering if the code ever panics and we have a if recover := 
> recover(); recover != nil {
>
> in a defer func and we are using sync.RWMutexes which do not have a defer 
> to unlock for example.
>
> What kinds of things can happen if the code unexpectedly panics when we 
> are in a Lock() in the code and then something panics before it Unlocks.  
> My defer funcs almost never unlock the syncRW mutexes or any RLock()'s that 
> were called to unlock.
>
> Should maybe if we are in the recover() block should we then call Unlock() 
> or RUnlock on all sync.RWMutex's that the function is recovering from?  How 
> would one know if you are in a lock or not if we made it far enough to open 
> the lock to know which ones to unlock if it truly keeps the lock open?
>
> Since we rarely get panics and we are dealing with some deadlocks, I am 
> asking myself this question and dont really know how to test it easily to 
> verify what really happens.
>

-- 
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.

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

[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 execution of the function until the defer.  It seems more efficient
> to only Lock and unlock between the specific lines of code where you are
> mutating a shared variable.

Yes, sometimes.  When you need to be careful about panics you can use
a helper function or a function literal.


> Still my question would be the same, on these existing locks if a panic
> happened and it exited prematurely, is it just safe to put any mutexes we
> are locked or RLocked inside of the recover if statement?  Just in case
> those are Locked or RLocked, will an Unlock or RUnlock always be okay and
> not panic further if they are not locked and we call Unlock or RUnlock?

No.  You must not call Unlock on a mutex that is not locked.

Ian

-- 
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.

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

[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()
do_stuff_with_a_locked(a)
}()
do_stuff_with_a_unlocked(a)
}

Perhaps more convincing:

func f(as []A) {
for _, a := range as {
func() {
a.mu.Lock()
defer a.mu.Unlock()
do_stuff(a)
}()
}
}

-- Juliusz



-- 
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.

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

[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 seems more efficient 
to only Lock and unlock between the specific lines of code where you are 
mutating a shared variable.

Still my question would be the same, on these existing locks if a panic 
happened and it exited prematurely, is it just safe to put any mutexes we 
are locked or RLocked inside of the recover if statement?  Just in case 
those are Locked or RLocked, will an Unlock or RUnlock always be okay and 
not panic further if they are not locked and we call Unlock or RUnlock? 

I swear I have seen golang get mad when you try to unlock something that 
has not been locked.  So I am trying to envision more the best way about 
this.

I think its too risky right now to convert all UnLocks and RUnlocks to a 
defered unlock because we have been through so many deadlock situations in 
the past.  I am a bit reluctant to keep something locked for the entire 
execution of a function everywhere.

On Tuesday, October 17, 2017 at 8:15:23 PM UTC-4, David Renne wrote:
>
> Hi there,
>
> I was wondering if the code ever panics and we have a if recover := 
> recover(); recover != nil {
>
> in a defer func and we are using sync.RWMutexes which do not have a defer 
> to unlock for example.
>
> What kinds of things can happen if the code unexpectedly panics when we 
> are in a Lock() in the code and then something panics before it Unlocks.  
> My defer funcs almost never unlock the syncRW mutexes or any RLock()'s that 
> were called to unlock.
>
> Should maybe if we are in the recover() block should we then call Unlock() 
> or RUnlock on all sync.RWMutex's that the function is recovering from?  How 
> would one know if you are in a lock or not if we made it far enough to open 
> the lock to know which ones to unlock if it truly keeps the lock open?
>
> Since we rarely get panics and we are dealing with some deadlocks, I am 
> asking myself this question and dont really know how to test it easily to 
> verify what really happens.
>

-- 
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.