10:48am, Elizabeth Mattijsen wrote:
> 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.
Thanks for the insight into this aspect of ithreads. It shouldn't affect my
particular project too much (an mp3 player), but it's good to know, and I'm
planning on checking out your forks.pm module.
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?
Also, what about the shared variables in 5005threads? Was that the same
copy-per-thread, or did 5005threads do things differently?
> 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.
>
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.
Thanks,
Paul Archer
----------------------------------------------------------
Reporter: "What do you think will be the biggest problem
in computing in the 90's?"
Paul Boutin: "There are only 17,000 three-letter acronyms."
----------------------------------------------------------
