If this article is news for you, this might be a helpful corollary:
Threads and processes are both units of execution. (A unit of execution is like a virtual processor -- a separate instruction pointer that makes its way through your code, doing computations and following jumps.)
Both threads and processes have their own stacks. You reserve a new stack when you fork(), or when you spawn a thread.
But only processes have their own heaps. In fact, this is the defining distinction between threads and processes: if you're sharing your heap with other execution-units, you're a thread; if you have your own isolated heap, you're a separate process.
Address spaces are just an implementation detail. You can have both processes and threads on an architecture without any such concept. The point -- the theory -- behind processes, is to separate your heap from your neighbor's heap, so pointers in your heap pointing at addresses in theirs won't be valid, or vice-versa. You could do this with virtual-memory mapping, memory segmentation, tagged pointers, domain-taint as static type checking, etc. and you'd get the same result.
Why only the heap? Since pointers on the stack can only (coherently) point into the same stack, or to the heap--and pointers on the heap can't point back into any stack--then stacks are already isolated. (Registers follow the same isolation rules as stack entries, if you want a register-machine.)
The reason you want to isolate your heap in the first place, the benefit you get, is that an isolated heap is an isolated graph for any garbage-collection system to pass over, and an isolated set-of-blocks-of-bytes for an exception to throw out or the OOM killer to discard. As soon as you have an isolated heap, in other words, you get all the practical advantages that come with running in a separate process.
If you implement a bytecode interpreter that can concurrently switch between several instruction pointers with their own stacks, then you've implemented green-threads. If each of those instruction pointers also has their own heap, you've implemented virtual processes.
If you are programming to the level of abstraction of an ISO C or C++ program (or a higher-level language/abstraction), then the stack and heap are your primitives and address spaces are an implementation detail.
If you are programming to the level of abstraction of POSIX, then address spaces are fundamental and the stack and heap are just convenience interfaces around mmap().
The fact that the StackOverflow question was asking for more OS-level details than the existing explanations they had found suggests that this is the time to provide actual implementation details instead of answering in more abstractions.
I'm not talking about programming, I'm talking about computer science. A heap (really, an object reference digraph) is a mathematical object that you can prove theorems about. An address space is just one way to isolate a block of memory, a way to enforce on a Von Neumann architecture the preconditions that allow for that mathematical object to be instantiated and manipulated. Not every machine is an x86 with an MMU.
> A heap (really, an object reference digraph) is a mathematical object that you can prove theorems about.
So is a Pseudo-Riemannian manifold. But neither of these is what the person was asking questions about. They were asking about programming on computers with operating systems.
Threads and processes are both units of execution. (A unit of execution is like a virtual processor -- a separate instruction pointer that makes its way through your code, doing computations and following jumps.)
Both threads and processes have their own stacks. You reserve a new stack when you fork(), or when you spawn a thread.
But only processes have their own heaps. In fact, this is the defining distinction between threads and processes: if you're sharing your heap with other execution-units, you're a thread; if you have your own isolated heap, you're a separate process.