|
Re: Multi-Threading in Perl
by IlyaM (Parson) on Dec 25, 2001 at 18:53 UTC
|
You have to build Perl with threading option if you want to use native Perl threads. Thread.pm is not even installed if you compile Perl without threading option.
There are exist some alternatives to native Perl threads. You can use POE.
--
Ilya Martynov
(http://martynov.org/)
| [reply] |
Re: Multi-Threading in Perl
by vladb (Vicar) on Dec 25, 2001 at 20:16 UTC
|
Hello,
Why is there a need for some 'threading' mechanism in Perl whereas it already has the 'fork' call? It appears to me
that around 90% of all that threads (such as in Java) are
useful for could be accomplished with the native fork() call
in Perl. Also, by playing with SIG triggers/set_priority call you may be able to do without a separate threading module/mechanism.
On the other hand, though, I think it's good to have alternative approaches. Say, I'm not even sure if fork() would work well on Windows (I don't do much Perl for that system), since under Unix fork() does a 'system call' to create a child process.
|
"There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith
|
| [reply] |
|
|
Threads are much more efficient. Fork() duplicate the entire process, thus needing A LOT more resources. It is also harder to have 2+ forks() communicate (PIPE or socket or shared memory) vs direct access to all data structures (this of course can lead to other problems though.)
| [reply] |
|
|
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] |
|
|
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] |
|
|
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] |
|
|
Excuse me for having to make this separate thread, but here's an article that I found posted on this site by a fellow monk. It relates to 'threading' and how to use fork() under Windows OS for that matter (after all the functionality _is_ there... ;-).
http://www.geeksalad.org/fork/all.html
|
"There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith
|
| [reply] |
|
|
while fork() does work under windows it has a number of problems. If you use a module that has XS that is not thread safe fork() emulation will probably crash your program. It also has a problem with the regular expresion engin under some circumstances.
Any one wanting to use fork() on windows should read the perlfork docs throughly.
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
|
Why is there a need for some 'threading' mechanism in Perl whereas it already has the 'fork' call?
It's hard to share data structures across a fork().
Yes, you can always get the job done using shared files, signals, pipes and such. But for some things it's just a lot more clean to pthread_mutex_lock(), change a variable, and pthread_mutex_unlock(). And select() loops are just obnoxious compared to having a separate thread or process to handle each incoming network connection (as long as you're not expecting super high performance with lots of clients)
Perl's threading works nicely - but it doesn't port to every platform perl does. This has caused me to rewrite at least one app which was originally started in perl using C. Good thing I "planned to throw one away".
| [reply] |
