Whether to use threads over processes, or to use processes over threads? I am sure that, not just we monks but all Perl users have quite different ideas on this, and could go totally opposite directions.
It is neccessary to have a thread for this, so that everyone can have a voice. We should make this an open-end discussion, as I strongly believe a healthy and fruitful discussion should be like that.
Multi-process and multi-thread are two types of concurrent programming models, and all languages have the choice to implement them. Although the models are not special to Perl, Perl does have its specials on this topic, that is Perl's thread is quite new, and unfortunately started with a not-ideal design, but I still would like to use threads over processes.
Now let me go the main topic, why use threads over processes? (well, I am sure lots of replies will be why use processes over threading ;-)
Creating a new process can be expensive. It takes time. (A call into the operating system is needed, and if the process creation triggers process rescheduling activities, the operating system's context-switching mechnism will become involved.) It takes memory. (The entire process must be replicated.) Add to this the cost of interprocess communication and synchronization of shared data, which also may involve calls into the operating system kernel, and threads provides an attractive alternative.
Threads can be created without replicating an entire process. Futhermore, some, if not all, of the work of creating a thread is done in user space rather than kernel space. When processes synchronize, they usually have to issue susyem calls, a relatively expensive operation that involves trapping into the kernel. But threads can synchoronize by simply monitoring a variable - in other words, staying within the user address space of the program.
The performance difference is also a winning point for thread over processes. The testing and prove of this itself can be a very big topic, and there are lots of numbers and well accepted testing results, which you can find all over the places.
Yes, multi-threading programming is more complex, and requires a different set of skill, and more importantly a different set of mind. I realize that this is actually one of the major reason why lots of people tried to avoid it from the beginning.
Back to Perl 5.8 thread, obviously it has lots of problems, such as unbelievable huge memory leaks, lacking of basic functionalities, but those are problems of Perl's implementation, not a problem of the threading model itself. I trust Perl creators are trying their best to fix those. In fact, if you read Perl 5.10's threading doc, the memory leaks are getting tamed, if not entirely.
One reason that you can start/continue with perl thread, even with so many bugs is that, I trust they will try every effort to fix those with minimum modification to the existing interface, as they are wise people. You can see this pattern base on their design considerations towards Perl 6. On one hand, people are benefited from Perl's rich functions and unique strong points, at the same time, Perl creators are trying to attract people, and there are certain conventions they have to follow.
More threading functions (interfaces towards end users) will be added, but that does not negatively affect existing Perl prorgams done in multi-threading. To be frank, you can never avoid modification to existing programs, regardless of how well it is designed and implemented, unless it will soon be replaced by something else. This because, people always want to utilize more (if not the most) advanced new technology (technology is progressing al the time), as well as user requirements are changing with active applications
Perl 5.8 threading does function, and you can expect your multi-threading programs getting better result with future Perl versions without much modification to your application. For example, most likely, their fixing of momery leaks would not affect your coding at all (from a static point of view, not from the execution point of view, obviously you would get better execution results.)
When you design or implement something, you should always try to create a foundation that survives the future, not just today.
Now go back to the level beyond Perl again. There is a good reason why Perl creators wanted threading in Perl. Without threading, Perl's usage will be framed tightly, Perl creators obviously realized this. Remember Perl is no longer a traditional scripting language, it is a violation of the creation purpose, to go without threading.
For some applications, people and firms, it might be a good idea to wait for a while before picking up thread, but picking up thread will eventaully becomes a decision one cannot avoid.
To be frank, the technology trend of using threading over processing whenever possible, is already a long gone old time story to the computer science itself, but unfortunately in the Perl world, real thread is quite new.
As some Perl programmers are still trying to avoid threading, lots of people were trying to avoid perl simply because it didn't support multi-threading. This is real story around me, and I am just telling the truth.
When some of us are trying to avoiding thread, Perl creators is using threading as a selling point. Is that pure commercial? I don't think so.
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |