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.
