I guess the equivalent Perl5 is to create an iterator and threads and one thread pushes onto the queue and another one takes off the queue? So you have essentially a bucket brigade of threads. Each thread performs a filtering process and passes on to the next filter. So what is the approach to scale this idea so that each filter can be replaced / modified / added / deleted?

Unfortunately, the overhead of Perl's implementation of shared data is such that passing individual pieces of data between threads becomes prohibitively expensive.

This can be mitigated to some extent by batching the individual elements into chunks. This is fairly easy to do using a wrapper class over the Thread::Queue module; or better yet, a custom queue module that avoids locking contention by batching to a non-shared buffer and only locking when a buffer is ready to be exchanged.

Another alternative it to use either pipes or sockets for the transfer of data; both of which do their own batching (buffering), but unless you carefully design the size of the elements to fit those buffers, it can lead to less than optimal transfers because of elements straddling buffer boundaries.

The fastest, most efficient solution is to drop into C for the queue, and bypass Perl's shared memory entirely. Unfortunately, the per thread, memory allocation pool model employed by threaded perl's makes this far more difficult to realise correctly than it should be.