My approach with the Net::CIDR::Lite doesn't seem to play with threads... So I am falling back to a simplier (non-object) approach.

My code above works fine with threads--but do it the hard way if you must.

Just an FYI, I ran (3 times) your code in a VMware(6.0.4) RH9 on top of WinXP and ended up with 3 Segmentation Faults after 5850|5377|6055 lines of output.

RH linux on top of VMware on top of XP! Sorry, but you get what you ask for in this life :)

As for the segfault, it is:

1. In Math Random::MT, which is only used to generate IPs and so is not a part of the solution you would use.

   Specifically, it is the XS code in M::R::MT that is trying to free up a C-runtime allocated (malloc'd) buffer that has apparently already been freed.

   Traditionally in C, is was not an error to free a pointer more than once which may explain why the error doesn't crop up elsewhere.

   VMs have nasty hacks under the covers to map calls to the virtual OS they are running, through to the hosting OS, which places far more stringent requirements upon the code they run than any author writing for non-VM hosted code needs to consider.

   It is up to you the user of other peoples code that you wish to run in a virtual environment to choose wisely or fix it yourself.

2. You could just substitute calls to Perl's in-built rand and my demo would probably run fine, although the range of IPs generated would be limited under native Win32 due to the PRNG only generating 15-bits. Under *nix it is generally a 48-bit PRNG.

You'll probably find you have far more trouble getting your shared hash approach running than you would the Net::CIDR::Lite via client-server. And it will probably run far more slowly as with a shared hash, you have no option but to lock the entire has every time, which means that which ever thread locks the hash, all the other threads will block if they need access.

Anyways, good luck.