On Friday, 14 May 2021 at 15:30:53 UTC, Markk wrote:

D rox ☀️

Let's improve it so it becomes perfect 😁

On Friday, 14 May 2021 at 13:48:12 UTC, Markk wrote:

I'm very much against binding any dynamic memory to any thread. It collides with a lot of programming models. For example threads created outside D, in C++ or any other language has no knowledge of D GC memory. This means that FFI is much more complicated.

Also threads are like prostitutes, they do the work of the client and then another client comes along doing some other work. Typically example are thread pools where any thread can do any work. Also bring fibers into the equation makes this even more unfitting.

Memory bounded to a thread is a bad idea and as time moves on it becomes more clear that a program should not assume which thread they are running (should only operate on self) and also not which CPU they are running on.

On Friday, 14 May 2021 at 15:37:22 UTC, IGotD- wrote:

Kinda agree on this. A thread is a virtualization of the cpu and a process is a virtualization of the memory.

On Friday, 14 May 2021 at 15:30:46 UTC, Adam D. Ruppe wrote:

I agree with that statement, but then I also believe that D should address the GC concern. Given how close D already is, it would be a shame not to.

:-D

_Mark

On Friday, 14 May 2021 at 13:48:12 UTC, Markk wrote:

Isn't that what Nim already has, thread local garbage collection?

I thought there was a problem to equip that in D, I think it relates to traced vs non traced pointer, though I'm no expert on this.

I wanted to know more why we can't do this in D because I like the idea in general.

However, I'm favoring more a task based solution mentioned already by Ola, i.e. a green thread based local GC as you could to concurrency without threads.

On Friday, 14 May 2021 at 15:30:46 UTC, Adam D. Ruppe wrote:

nobody complain about the GC

people complain about the fact everything is modeled around the idea of a poors man GC, implemented and served to everyone by force

On Friday, 14 May 2021 at 15:37:22 UTC, IGotD- wrote:

I disagree by 180°. If the memory management is associated with the thread, such "foreign" threads would be completely left alone by D or the GC, and that's exactly as it should be. Passing memory from/to that thread to a D thread is already a difficult thing to do right, this proposal would make that safer and more formal.

Again, I disagree. Please read my earlier post about how the Allocator assignment could be scoped (e.g. by the pool bootstrapper) https://forum.dlang.org/post/mqfuxbuuhpvqeyvxoang@forum.dlang.org, Pool usage could be supported in a very natural way and be very fast, because for short tasks, the GC would never run and all the memory could be jettisoned en bloc when the thread task goes out of scope.

Obviously fibers need to share the same thread heap/Allocator. Other than that, scoping/RAII (of the pinned references) is still valid and this is the most important thing. The limitations/language guarantees would sometimes be overly strict between fibers of the same thread, but they are still valid. Fibers are scheduled cooperatively, i.e. non-preemtively, so the premise to make the GC simpler/faster, holds. So what is the problem, exactly?

This contradicts everything I read about locality becoming more and more important with modern multi-core processors. The following is simply the best article I ever, ever read about the issue. I recommend reading it:

https://www.informit.com/articles/article.aspx?p=1609144

_Mark

On Friday, 14 May 2021 at 17:02:00 UTC, Markk wrote:

If for example C++ calls a D function, the D function does something temporary with arrays then those arrays will not be cleaned up if the array memory is thread local.

More likely since the thread has no meta data in D, some error will happen. The programmer will sure know it but this is very inconvenient as the D function will not work if called outside D.