Creating a timer thread to kill timed out threads seemed very easy and handy.

That sounds simple and convenient, but threads have state. And if you go around just killing them, you don't give them the opportunity to clean up after themselves and that's where 'mysterious' memory leaks arise.

Creating a fork within a thread with a signal handler killing the fork on the other hand would be a lot more expensive.

I certainly agree with you that that is not a viable option.

But there are better alternatives to both those approaches. The details depend upon the type of "network related issues" you are concerned about?

In general, using cancellable asynchronous IO or non-blocking IO, within the thread, to allow you to abandon slow or broken connections, is a viable alternative. It allows you to retain the benefits of threading: simplicity of 'serial flow' architecture; scalability across cores; whilst avoiding the traps of 'throwing threads at the problem' & the difficulties of clean-up associated with abandoning threads.

You gain the benefits of a non-blocking IO, without the need to invert the flow of control, or have the need for abandonable IO to dictate the architecture of your entire application.