On Tue, Oct 17, 2017 at 5:03 PM, <davidre...@gmail.com> wrote:
>
> 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.
If a mutex is locked, and a panic occurs, and there is no defer
function that unlocks the mutex, then the mutex will remain locked.
> 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?
Typically people write code like
mu.Lock()
defer mu.Unlock()
so the deferred Unlock is only executed if the mutex was 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.
