Re^2: [OT] Software Architecture - Pipe and Filter

[trippledubs]

Data Source ->Pipe -----> Filter ----->Filter --------->DataSink
                            |                              ^
                            |                              |
                            |                              |
                            ->---------Filter--------------^

So in Perl list context gives the ability as with Unix pipes to pass from one filter to the next, but the list is completed before it goes on to the next stage, there is no concurrency, right? Even though it seems like there should be. Trying to find a good example:  map { $_^2 } grep { isPrime($_) } grep processes the whole list before map processes the first element? Why?

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?

I found this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3534.html And also the Perl6 Documentation (sorry) talks about concurrency - http://doc.perl6.org/language/concurrency as in the language itself supports this paradigm of programming with Promises and Supplies -- maybe. Is there some kind of equivalent feature in Perl 5? Maybe this: https://github.com/skaji/Process-Pipeline

Basically map and grep but acting in parallel, asynchronously, rather than in sequence.

[BrowserUk]

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.

[LanX]

> Not thinking that is going to provide timely results. What kind of programming solves those kinds of problems.

I've been told that the go-language is good in such things, but can't provide much insight.

[trippledubs]

Yes! So it looks just from briefly searching 'go concurrency' that go https://www.golang-book.com/books/intro/10 has a couple APIs, goroutines and channels that match up nicely to this type of problem. Even a 'select' switch that will block until any of many channels has data ready to process. Thanks.