On 10/19/06, Levi Pearson <[EMAIL PROTECTED]> wrote:
If passing messages or setting up explicit shared memory turns out to be far more awkward, and your problem doesn't involve too many hairy locks and such, threads might be a good solution. But in Linux, you shouldn't reach for them unless you've clearly demonstrated to yourself that the benefits outweigh the costs.--Levi
I always just go with threads. But then again, I do a lot of desktop software, where interaction between components is frequent and shared memory is more efficient, reliable, and convenient than message passing via pipes or some other IPC mechanism. I'm not saying that Levi's points aren't valid, on the contrary, they are. Memory space protection provided by a process is valuable... Valuable if you're using C, or some other language that can stomp on or leak memory. If you're using a language with memory management (Perl, C#, Java, Lisp), then the protection provided by processes has little value and some down sides. I find the protection provided by processes to be overrated. You can achieve a much more natural programming model by using threads and semaphores, than processes and marshaled messages. I would complain that forking has memory overhead too because you have to make a complete copy of your stack/heap for the forked processes, but Linux is sweet and employs a copy-on-write technique where the forked process uses the parent's memory until it tries to overwrite a value (then a copy is made). Am I crazy, do other non-C/C++ developers really like processes more than threads? -Bryan /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
