Common patterns to work around the limitations of thread-local gc?

Question

In my process of learning Nim, I'm currently studying Nim's approaches to concurrent programming. I have seen a few comments about the limitations of a thread-local garbage collection (for instance here and there), but I still don't fully see all implications of this.

I'm wondering if there are some kind of well-established "design patterns" in Nim how to deal with these limitations? Maybe it is possible to consider a typical example that requires inter-thread sharing/interaction and to show possible idiomatic solutions to such a problem?

My own attempts to come up with good solutions to this were not really successful so far and have lead to this more specific question about TChannel.

Ivelisseivens

Answer 1

A really broad answer is: This seems to go against the design principles of Nim. Nim completely avoids any inter-thread sharing/interaction problems by removing that as a capability. The no "stop the world" design principle. The built in asynchronous message passing should be adequate to.

What limitations are mentioned in the referenced articles seem to be limitations in design or approach to the problems.

Also in the time passed since you posted this question I see that there has been an answer to the linked TChannel question. Has this resolved your issue?

@bluenote10 Is it possible you can better define the type of problem you are facing? The way it seems now this question is really broad. Also sorry I don't have the rep to reply directly to you.

Comanchean

the limitations [...] seem to be limitations in design or approach to the problems. So the question becomes: Which design/approach would avoid the limitations? I'm not asking for a specific problem. What I mean by "design patterns" is a kind of categorization of common concurrency problems and a guideline of how to approach them in Nim. – Ivelisseivens