If you need shared data, you have the option of delegating the data to an external instance or to share it somehow via classical IPC mechanisms, shared memory segments, message queues, pipes and such - but you basically need the same synchronisation mechanisms as with threads (in come semaphores), and sharing complex data structures is IMHO some hells more difficult using IPC.But that's actually a good thing. The fact that it's a pain to share complex structures will make you rethink your application. If it's easy to share complex data, you'll end up taking a performance hit, because more and more of the data has to be locked because you're doing it blindly.
And the default should be not shared, rather than shared. fork() ensures this. Threads is biased towards shared.
Multiple threads of execution is hard. It should stay hard. There's really no way to make it easy. "threads" pretends to make it easy, and what you end up with are fragile programs because average dudes get in over their head. At least with fork, it's a pain to share things, so average dudes delegate the tricky parts to libraries that do the sharing written by smart dudes, or figure out other ways, like sharing through databases.
Maybe that's why I object to threads: it makes it too easy to get in over your head. It takes far more expertise to use threads than most people have, which is less than they think they have. {grin}
-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.
In reply to Re^5: Parrot, threads & fears for the future.
by merlyn
in thread Parrot, threads & fears for the future.
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |