News for hackers. Stuff that matters.
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...
Re:GoDoc: package letsencrypt by bouk on Tuesday September 20, 2016 @12:52PM (#12540964)
`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
Re:GoDoc: package letsencrypt by barpet on Tuesday September 20, 2016 @10:16AM (#12539639)
no reason imho..the function is pretty trivial. But also not a reason not to use it as a performance impact would be minimal :-)
Re:GoDoc: package letsencrypt by junke on Tuesday September 20, 2016 @10:46AM (#12539898)
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.
Re:GoDoc: package letsencrypt by alpb on Tuesday September 20, 2016 @01:57PM (#12541636)
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.