Liz: Thank you for your quick response to my questions.
<snip> > I'm afraid these prerequisites will disqualify using Perl ithreads > for your application in a production setting. This is caused by the > fact that each Perl ithread gets a _copy_ of all data-structures in > each thread. In practice, this means that even with a small number > of modules loaded, the memory footprint soon becomes very large. <<< Oh well. I suppose if the ithreads overhead were lighter this approach would make sense. I can't overburden my machine with too many resource constraints as you suggest would likely exist. <snip> > If you're going to need thousands of threads, you're going to need a > lot 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. <snip> > > If you still want to use Perl ithreads, and are not worried about > performance 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. <snip> > I'm afraid there isn't too much chatting going on here lately. But > the list does get monitored by some people. ;-) > > In any case, I hope this helps. <<< Yes, it was quite helpful and will likely save me a great deal of time and headaches. My sincerest thanks for your time and wisdom. Steve
