[nabucodonosor]

wondering why not using `defer m.mu.Unlock()` right after line 279: https://github.com/rsc/letsencrypt/blob/a18c646c3d0772313b7b...

[bouk]

`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

[barpet]

no reason imho..the function is pretty trivial. But also not a reason not to use it as a performance impact would be minimal :-)

[junke]

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?

[schmichael]

Given the current code and no races against the values being initialized: no, there is no chance for a panic.

[alpb]

This is not a good assumption. The code will panic, for instance when it can't allocate memory, or runs into signal handling issues.

[nabucodonosor]

understood. thank you.