"Shawn Rutledge" <[EMAIL PROTECTED]> writes: > I'm inclined to agree with the argument that as long as forking has a > low enough overhead, processes are better than threads for > general-purpose parallelism. Especially considering that if you are > using memory to share state between threads, you will always be > limited to a shared-memory architecture - you cannot move the program > unmodified onto a cluster. But there is more data-copying involved > with message-passing, compared to just accessing the same memory. > Safety and portability have their price.
Your attitude to threads is just a prejudice with no support behind it. Most overhead originates not from fork, it comes from copying and IPC. Passing data between threads may be as simple, as assignment. Note: no context switch involved. Passing data between processes is almost always two context switches, synchronization in kernel, and copying passed data at least twice, unless you use some very system-specific hack. Sometimes you can avoid redundant copying by mmaping common file, which still brings you to shared-memory and all the stuff connected. There's the price of your prejudices in terms of performace lost. If you work within properly choosen framework, you may care very little about what you are running actually, a thread or a process on another machine. Having one subroutine, that merely passes the pointer to locals and communicate over network to remote, is easy enough, if you don't pass linked structures. -- CE3OH... _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
