3 ms·
It actually does not solve the problem of lifetimes. It only solves a very isolated instance of it. For example, if we take the problem of an os.File, some lib
by arghwhat 9y ago
It actually does not solve the problem of lifetimes. It only solves a very isolated instance of it.
For example, if we take the problem of an os.File, some library might store the reference, and use it unexpectedly in a later function call after you called Close. This presents the exact same issue as a goroutine holding it.
(I honestly have no other examples of this issue than files/connections being closed prematurely for Go.)
- wybiral 9y agoI've never encountered a situation in Go where I'm passing file handles around like this. In practice you'd probably have one goroutine manage the resource and its lifespan then other code would communicate with that goroutine using channels.
- arghwhat 9y agoYou might pass an os.File or a network connection as an io.Reader or io.Writer to something that might keep it. The GC actually has an extension to sorta have destructors to help with leaking fd's from forgotten os.File's (runtime.SetFinalizer). However, having coded Go for quite a few years by now, I haven't found it to be an issue at all.