Hacker News Reader

Comment by peheje | Hacker News Reader

I really like Nim. I hope the threading interface improves though, I found it lacking last time I checked about half a year ago.

View on HN

I'm curious, what more are you looking for? From the nim manual:

"Each thread has its own (garbage collected) heap and sharing of memory is restricted to global variables. This helps to prevent race conditions. GC efficiency is improved quite a lot, because the GC never has to stop other threads and see what they reference. Memory allocation requires no lock at all! This design easily scales to massive multicore processors that are becoming the norm."

To me, that sounds perfect for writing typical apps.

How does Nim do thread-based GC if an object is shared across threads? Does it not allow that sharing references cross-thread (not sure how it would without lifetimes though)?

If I understand the Nim manual correctly, there is no sharing of objects across threads. Instead, Nim assumes message passing. When you communicate between threads, Nim makes a deep copy of the message.

In theory, that strategy could be very inefficient if the messages are large, but it also means the garbage collector is unaware of threads and therefore simpler.

>there is no sharing of objects across threads

You can message-pass a pointer if you are sure the referenced object won't be GCed.

You communicate via channels, like in Go. Objects passed through a channel are deep copied. To share an object, you can create an actor thread that owns it, or if you're sure the object won't be GCed (i.e. by exempting it with the `GC_ref` function), you can pass a pointer through the channel.

Reply on news.ycombinator.com