Giving an example, in perl, would be counter-productive as it would invite comparisons, that would only serve to highlight the shortcomings of the current implementation of perl's threading.

In essence, in filter type applications, reading from a file, performing some processing, and then wrting to another file, much of the time is spent waiting on the kernel to complete IO. Throughput can be vastly improved by having a read thread, a processing thread and a write thread. Written correctly, this allows the processing thread to run at full speed, overlapping the processing with the IO.

This processing model only works if the three threads can share the buffer space for input and output. Forking doesn't work for this as you then need to use IPC to communicate the data between the 3 processes, and instead of the processing thread having to wait on the reads and writes, it has to wait on the IPC. You've just moved the goalposts, not removed the waiting.

Unfortunately, using the current implementation, even using pre-spawned threads, the underlying duplication/replication in perl's shared memory model, combined with the course granularity of the semaphoring, don't allow this model to be coded as efficiently, hence I won't provide sample code.