> If you're going to need thousands of threads, you're going to need alot of RAM. And the copying of data becomes a considerable CPU burden as well. But I don't need a lot of data, you say. Well, you do need modules, and modules contain subroutines and variables. And> those are all data. <<< It isn't clear to me that I would ever need more than three threads (one for each socket), but even those are seemingly expensive.
Well, in that case I don't think there really is a problem. Only three threads is not a problem, especially if you can start them early, preferably during compile time. Thousands of threads, that _is_ a problem. ;-)
> If you still want to use Perl ithreads, and are not worried aboutperformance per se, you might want to have a look at the forks.pm module I wrote. It basically has the same interface as Perl ithreads, but uses fork() to start threads (hence its name). It also uses a TCP connection for each thread that has shared variables, so> that may turn into a lot of sockets in your case. <<< At this point I don't think the ithreads approach is a logical path for my needs. Perhaps I'll take another look at it when Perl v6 is released. I can probably get away with running small parallel processes for external communications and sharing the data via pipes, shared memory, etc.
That is definitely an option. Perl 6 will have threads running as the blood through its system (well, Parrot continuations, actually, but who cares ;-)
> I'm afraid there isn't too much chatting going on here lately. But > the list does get monitored by some people. ;-) <<< Yes, it was quite helpful and will likely save me a great deal of time and headaches.
There's something to be said to be "modern" and there is something to be said for being "conservative". In retrospect, if you only need three threads, then I think it would definitely an option. But if you're cool with pipes and shared memory, then please use that: it will also work!
My sincerest thanks for your time and wisdom.
You're welcome ;-)
Liz
