Threads::Queue has been backpanned.

Sorry, typo. It should be Thread::Queue per the usage in my example:

my $Q = new Thread::Queue;
[download]

(and no. You don't have to use indirect object syntax :)

Also, it seems that all solutions are suggesting lightweight processes. But I have 2 cpus, why shouldnt I be going for 1 heavyweight process per CPU, one for the file reading and writing and the other for a database commit.

No reason except that then you'll need to communicate between processes. IPC is mostly not portable. Mostly inefficient. Mostly a pain in the tush.

You need a communications channel: pipes, sockets, or shared memory.

You need a communications protocol or interprocess semaphores.

But mostly, you just moved the problem. Now you have to block on reads and writes from your IPC channel.

Thread::Queue is available, tested and works well.

You're also barking up the wrong tree thinking of it as one process per cpu. Each process (or thread) will get run on which ever cpu comes free first when it is next ready to run. both processes or threads could end up always running on the same cpu because some other process in your system is hogging one of them.