Okay, I guess the question I have is, why do you need to fork before creating threads? Are you running this on win32? some nix flavor? If its win32, then the threads and actually forks, and using threads aren't really saving you much of anything
Note, in the code you've posted, you have a scope problem:
if ( $thr->tid && !threads::equal( $thr, th +reads->self )
+ ) {
##########Not Sure #######
foreach my $client ( keys %sharedHash ) {
print " client $client\n";
my $thrnew = thread->new( \&compare, $client );
$sema->up;
}
$sema is not defined in this context, its local to the previous loop. there are numerous other bugs, but i'll leave that to you to find ;)
Again, I would refer you the the thread primer http://perlmonks.org/?node_id=691785 and the like http://perlmonks.org/?node_id=704138, but I've made a stab at doing what I _think_ you are looking to have done
Note that the control structure of what I've done is _extremely_ sloppy and I would not reccommend it.
note that i don't quite understand why you need to thread your compares, but, I guess if that is also a time consuming operation, it could make sense
also note that I made your worker sub and compare sub local to the sub that is running in the fork. I did this for my own readability, as well as to remind myself that they are really running in the scope of the forked process and not the main program
In that vein, in my shared hash, I did not need the pid as a key in the hash, I just put it there for clarity, each forked process will be local unto itself, only copying the values, etc that are available at the time the process is forked (at least the way I understand the world
anyhow, hope this is helpful |