The future of "frozen" types as the number of CPU cores increases

[sjdevnull at yahoo.com]

On Feb 23, 8:03 pm, Nobody <nob... at nowhere.com> wrote:
> On Mon, 22 Feb 2010 22:27:54 -0800, sjdevn... at yahoo.com wrote:
> > Basically, multiprocessing is always hard--but it's less hard to start
> > without shared everything.  Going with the special case (sharing
> > everything, aka threading) is by far the stupider and more complex way
> > to approach multiprocssing.
>
> Multi-threading hardly shares anything (only dynamically-allocated
> and global data), while everything else (the entire stack) is per-thread.
>
> Yeah, I'm being facetious. Slightly.

I'm afraid I may be missing the facetiousness here.

The only definitional difference between threads and processes is that
threads share memory, while processes don't.

There are often other important practical implementation details, but
sharing memory vs not sharing memory is the key theoretical
distinction between threads and processes.  On most platforms, whether
or not you want to share memory (and abandon memory protection wrt the
rest of the program) is the key factor a programmer should consider
when deciding between threads and processes--the only time that's not
true is when the implementation forces ancillary details upon you.