I have been working on exactly this problem lately and got a massive amount of help from BrowserUk++. Please see multithreaded tcp listener with IO::Socket for the discussion and some excellent code Re^7: multithreaded tcp listener with IO::Socket.
The main trick is in passing the file handles to a pool of threads that handle the connections and a little bit of trickery to stop them going out of scope too soon.
For my problem I have an architecture like this ...
1 main/listener Thread
listens for connections
passes socket via queue
cleans up old sockets
Pool of receiver threads
check data and send OK or ERROR to client,
instruction to close socket back to main thread
and puts ref to data on another queue for...
Pulls refs off the queue and decides which of several
handler threads will get it (may be one of more).
spawns handler if it is not yet running then puts
ref on queue for that handler.
do thing like logging, hearbeat monitoring
forwarding exceptions to a console etc etc.
Self Heartbeat Thread
Send periodic heartbeats through its own
mechanism to another monitor console so
we know it is still working
I am also using this for performance monitoring, stats gathering etc. Not sure how varied your data sources are, we have everything from heartbeats and disk space monitors to robots running synthetic transactions on our live web sites. One big step in making it all work was to define a common format for the event data. We have based ours on IBM's "Common Base Event". There is a paper out there called "Cannonical Situation Data Format: The common base event". It makes the rest of the code much simpler.
Pereant, qui ante nos nostra dixerunt!