10:48am, Elizabeth Mattijsen wrote: > I'm afraid these prerequisites will disqualify using Perl ithreadsfor 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. I'm curious about this memory usage per variable, though. If you don't share a variable, then that data shouldn't be copied from one thread to another, right? I mean, if one thread has a huge array, for example, then that shouldn't affect any other threads (or their memory usage) as long as the array isn't shared?
Nope. Wrong. The current Perl ithreads implementation copies everything data to each thread. Yes, I know it sucks, but that's the way it is right now. You can find some examples in a recent Perl Monks meditation: http://www.perlmonks.org/index.pl?node_id=288022 .
Also, what about the shared variables in 5005threads? Was that the same copy-per-thread, or did 5005threads do things differently?
5.005 threads didn't copy anything, but made everything shared. Even things you wanted private. And it was never production ready.
> 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. I'm curious about why you used TCP connections instead of Unix sockets. Was that to make it Windows compatible, or for some other reason? I understand Unix sockets are typically a good bit more efficient that TCP sockets on a local machine.
Primarily because I didn't figure it out how to use Unix sockets reliably from Perl. I'm accepting patches ;-)
Liz
