Re: Re: Multi-Threading in Perl

Replies are listed 'Best First'.
Re^3: Multi-Threading in Perl by Aristotle (Chancellor) on Dec 25, 2001 at 23:01 UTC
Depends. The real cost is usually not so much that of process creation as that of context switching while running. On most OSs, it is a lot cheaper to switch threads within a process, than switch between processes. Linux' context switching however is so fast (at least on Intel CPUs) that it can easily masquerade as threading and indeed in that kernel, "threads" are really just forked processes, with a bit of decoration to hide the separation. So the answer really depends on what you're going to run on. If you're primarily going to run on a modern Unix, fork is usually easier to work with than threads and it has much fewer pitfalls, like paying attention to who is accessing what variables and the likes which you run into when working with threads.	[reply]
Re: Re: Re: Multi-Threading in Perl by Aighearach (Initiate) on Dec 26, 2001 at 03:39 UTC
On Linux, and most nix, threads do not* copy the entire process. Only a very little is copied, and the rest is shared until the page it is on changes. That is why Linux can fork() faster than windows can create a new thread. So, forking or threading is a platform dependent issue. Which is why you shouldn't use the non-portable method (threads) in a language like Perl that is usually very portable. fork() should work on all platforms. -- Snazzy tagline here	[reply]
Re: Re: Re: Multi-Threading in Perl by LunaticLeo (Scribe) on Dec 26, 2001 at 22:04 UTC
Threads are much more efficient...It is also harder to have 2+ forks() communicate (PIPE or socket or shared memory) vs direct access to all data structures For the love of all that is holy why do you youngsters think this stuff. Free your mind (from Win32s land) and your code will follow. Efficiantcy: fork() + SysV shared memory is just as fast on Linux as threads. Further, you get the advantage of explicitly shared data, rather than the joys of tracking down obscure memory corruption bugs. Easy of Use: Unix process calls + SysV shared memory API are far more simple than the POSIX thread API and more useful to learn overall. Threads are faster for context switching than processes on old propietary unixen/winnt. That is because all those proprietary OSes were created to sell hardware. Why should they care about speeding up the common case? Unix is an amazing API. With proper implementation it is awsomely powerful, fast, and simple. Threads are a context switching optimization/abomination. However, perl threads could make POE really cool on multi-processor machines (re: thread per CPU to implement an explicit state machine).	[reply]


We don't bite newbies here... much
	PerlMonks