4 ms·

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

• barpet 10y ago
  no reason imho..the function is pretty trivial. But also not a reason not to use it as a performance impact would be minimal :-)
  • nabucodonosor 10y ago
    understood. thank you.
  • junke 10y ago
    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 10y ago
      Given the current code and no races against the values being initialized: no, there is no chance for a panic.
      • alpb 10y ago
        This is not a good assumption. The code will panic, for instance when it can't allocate memory, or runs into signal handling issues.
• bouk 10y ago
  `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