Re:GoDoc: package letsencrypt
by nabucodonosor on Tuesday September 20, 2016 @10:00AM
(#12539524)
wondering why not using `defer m.mu.Unlock()` right after line 279: https://github.com/rsc/letsencrypt/blob/a18c646c3d0772313b7b...
[ Parent
| on HN ]
`defer` mostly makes sense when there's multiple exit paths (returns) or if there's a chance any of the code panics. Neither is the case in this instance, so just doing it like that is fine. There is also a slight overhead for deferring, as it needs to allocate some memory on the heap
no reason imho..the function is pretty trivial.
But also not a reason not to use it as a performance impact would be minimal :-)
The behavior is different if a panic occurs, isn't it? But is there any chance that this particular initialization code might panic in the first place?
Re:GoDoc: package letsencrypt
by schmichael on Tuesday September 20, 2016 @12:33PM
(#12540805)
Given the current code and no races against the values being initialized: no, there is no chance for a panic.
This is not a good assumption. The code will panic, for instance when it can't allocate memory, or runs into signal handling issues.
Re:GoDoc: package letsencrypt
by nabucodonosor on Tuesday September 20, 2016 @10:24AM
(#12539736)
understood. thank you.