News for hackers. Stuff that matters.

A comment on Notes on structured concurrency, or: Go statement considered harmful. Parent comment

Re:Notes on structured concurrency, or: Go statement conside... by arghwhat on Wednesday April 25, 2018 @04:17PM (#16925621)
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.)

[ Parent | on HN ]
Re:Notes on structured concurrency, or: Go statement conside... by wybiral on Wednesday April 25, 2018 @08:01PM (#16927602)
I'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.

[ Parent | on HN ]
Re:Notes on structured concurrency, or: Go statement conside... by arghwhat on Thursday April 26, 2018 @03:48AM (#16929764)
You 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.

[ Parent | on HN ]