When thinking threading, I always viewed it in the eyes of user threading like in Java. Granted java is memory intensive, it still is efficient at the code level.

Please describe your application in some detail. Ithreads can be used to accomadate many uses, but it does require that you understand both their advantages and limitations.

Right now the application is built using forks. Each fork spawns off a DBI connection of it's own and reads in data from a text file based off the system it's currently updating within the database (data to update is gotten remotely by another script).

The restrictions I currently have and trying to fix is data sharing. Right now when I get an error, I dump it to a temp file and then read in the temp file at the end of the processing. This is possibly one of the most efficient ways of doing it due to the size of the load I have I still rather find something a bit more "less problemantic".

Hashes storing data like server hostnames and a hostname changes. I have a DB loaded hash containing all "active" systems. I need the ability to "change" that has in the case of a hostname change.

I'm also wanting to build an XML file containing human entered discription data for each system (right now it uses bunches of little name=val strings--one file per server). 300+ systems, while a single file might be too much, it's definatly too much for threads. Either case, when a hostname, etc, changes on a system, I need that change updated within the XML hash as well for dumping at the end of the script execution.