On Friday, 14 May 2021 at 15:37:22 UTC, IGotD- 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.
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.
> 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.
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.
> Also bring fibers into the equation makes this even more unfitting.
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?
> 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.
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