3 ms·
I really like Nim. I hope the threading interface improves though, I found it lacking last time I checked about half a year ago.
by peheje 7y ago
I really like Nim. I hope the threading interface improves though, I found it lacking last time I checked about half a year ago.
- hathawsh 7y agoI'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.
- KallDrexx 7y agoHow 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)?
- hathawsh 7y agoIf 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.
- btym 7y ago>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.
- btym 7y agoYou 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.