Is the new D threading model emulating processes + shared memory?

[superdan]

Leandro Lucarella Wrote:

> I was thinking about the thread "Sharing in D" and it came up to my mind
> that what it's been done with this model is just emulating processes +
> shared memory. If you program you application with processes instead of
> threads and shared memory instead of "D shared" type (or global variables
> in general), you get what D is trying to do: clearly separated memory
> areas for shared and unshared data, and protection.

that's real deep. changed the way i look at this shit. until now i was comparing the model with the perl shit. perl in concept does the same as d2. i used that perl model and like it a ton. it's slow tho because perl copies the whole heap to boot.

but i think u r right. it's like processes and shared memory. and you know what. i wrote those and never had a problem. problem is with threads because everything is shared by default without anyone wanting or knowing. only little should be shared. sharing must be controlled. seems d2 has the right view.

> So, what are the advantages of using threads+shared in D 2.0 compared with
> processes+shared memory in D 1.0? I guess it's just simpler to program,
> and maybe, more familiar to "threads programmers" (people that are not
> very used to program using processes). Well, I guess you can have a little
> faste context switches too, but I don't think this his a huge gain in
> modern operating systems.

to boot there is the overhead. creating a process is much a bigger deal than a thread. new tables and shit. then shared memory access costs too i recall. then also creating and dealing with shared memory is not for the faint of heart. for example pointers are meaningless unless you are really cautious and shit. and no typechecker tells you that. in d2 it looks like the type of shared memory is doing the right thing because it's transitive.