undefined | Better HN

0 pointsarghwhat8y ago0 comments

Knowing whether a background task has spawned is very different from not being able to follow the control flow (goto potentially jumping to an entirely different function body).

Now, while Go is designed mostly for you to not care about goroutines, there are some corner cases where one must know if a resource is used by anything, such as the chase of when you wish to close a file handle.

However, I'd argue that this is not related to go's concurrency model and the presence of background tasks at all. It's related to object lifetimes. This should be made clear at API surfaces.

A language solution to this would be Rust's lifetimes, not a new concurrency model.

0 comments

7 comments · 2 top-level

marcus_holmes8y ago· 5 in thread

But this concept does also solve that problem. Maybe more simply.

Rust is renowned for being a total headache with borrowing and lifetimes. Nurseries might be a simpler solution for this.

As you say, a corner case. But a common one...

lilyball8y ago

Nurseries and lifetimes are orthogonal concepts. In fact, Rust already has a "nursery", except it's generally called a scoped threadpool. They use lifetimes to ensure the threads can reference stuff on the stack without copying it. So a "nursery" is basically just a scoped threadpool with a 'static lifetime.

steveklabnik8y ago

There is some interesting stuff about this in the /r/programming thread https://www.reddit.com/r/programming/comments/8es8x3/notes_o...

stouset8y ago

I don’t think there’s any reason a nursery has to have a static lifetime.

2 more replies

arghwhatOP8y 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.)

wybiral8y ago

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.

1 more reply

noxecanexx8y ago

This is very true. The same way one doesn't know if a background was started is the same way you can't know if a file was written to or some global state was changed. I thought async/await solves most of his examples

j / k navigate · click thread line to collapse