Hence the existence of forks.pm. It has the improved efficiency of creating a new "thread" because it uses fork() to do that (clearly not something to use with a native-Windows Perl, of course). (It offers the same interface as threads.pm.)
I haven't used forks.pm myself. But I have worked with POE and I recently evaluated work done by some very smart co-workers who were using similar systems. People who work with something like POE frequently convince themselves that it isn't much of a burden (as I had).
Having a chance to look at it with hindsight and not from the middle of it, I was very convinced that the POE way of providing cooperative multi-tasking is indeed quite a burden, even after one has gotten used to the awkwardness. Even the simplest algorithm, if it can involve a pause (such as reading from a network socket) must be broken into pieces. And any routine that calls such a fractured routine must itself be broken apart. And anything that calls that, etc.
This fracturing also means you don't have much of a call stack and can't easily throw and catch exceptions across the fractures. It keeps getting in your way every day in small and large ways.
So, I don't consider using POE to be an untenable solution. But I believe it incurs enough of a cost that I wouldn't make it my first choice.
I believe that forks.pm and Coro are worth considering first, as they allow unfractured coding. Coro will not use multiple "cores", but in most cases I don't mind because I'm usually either using a system that has plenty of other things to do or I have $N servers dedicated to the task and can just run 4 Coro-using instances on each quad-core server (for example). But the limitation is worth keeping in mind as there are certainly situations where it is a drawback.
- tye
In reply to Re^7: Strange memory leak using just threads (forks.pm)
by tye
in thread Strange memory leak using just threads
by MnkyBrain
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |