> This takes away much of the point of threads, leaving you better off with processes---and process boundaries will better enforce this model. You cannot cons u

> This takes away much of the point of threads, leaving you better off with processes---and process boundaries will better enforce this model. You cannot cons up a message, pop it in a queue, and have another thread pick that object out the other end: thus you have to use some IPC based on bytes in a pipe or shared memory buffer. Not really true; a lot depends on the implementation here. In a multi-threaded setup you can often avoid context switches and kernel calls (the really expensive part) and deep copying with a bump allocator is generally cheaper than deserializing/serializing [1]. Often, you can also avoid copying if you do it right. On top of that, while you can't manipulate pointers on the heap safely under such a concurrency model, you can manipulate integers and floats across heaps (which is relevant for a large number of concurrent algorithms) if you do it right (i.e. by ensuring that you don't deallocate the objects containing the data). [1] Keep also in mind that any actual shared data that goes from one thread to another will generally go through main memory or the L3 cache at one point or another.