<div dir="ltr">Hi,<br><br>I managed to put together an implementation of Hartmann pipelines that are an extension to the pipes usually used in your OS of choice (see <a href="http://en.wikipedia.org/wiki/Hartmann_pipeline" target="_blank">http://en.wikipedia.org/wiki/Hartmann_pipeline</a> for more details).<br>


<br>The code and some documentation (some of it already outdated) is to be found at <a href="http://code.google.com/p/erl-pipes/" target="_blank">http://code.google.com/p/erl-pipes/</a><br><br>*Brief description:<br>
<br>Pipelines are formed by pipe segments connected to each other, forming a directed graph. Data flows through the pipeline and is transformed along the way. <br><br>A pipe segment is represented by a process and messages are bearers of the data flow. This allows multi-processor systems to split the load between the CPUs.<br>
<br>
There is a soft flow control mechanism (meaning that the control signals are not authoritative) that prevents mailboxes to become overflowed.<br><br>A few pipe segments are defined in pips_builtins. One of the more interesting ones is 'partition' that splits the flow in two, based on a user-supplied predicate. <br>
<br>See pipes_test.erl for some examples and a simple benchmark. <br>
This brings up the question of performance. Well, since I'm the author, I will be nice and say there's a lot of room for improvement. I've measured worst case runs that were 30x slower than doing this in the old-fashioned way, but I've also had cases where the slowdown factor was 1.4, which is not too bad. I suppose this kind of system would benefit a lot from a shared heap runtime.   <br>

<br>For this to be easy to use, we will need a simple way to put together the segments. A language to describe the graph that is "input friendly".<br><br>This is (I think) also a good example where channels might prove useful. <br>

<br>All in all, this is just a scratch on the surface. There is a lot to improve and to add. <br><br>best regards,<br>Vlad<br><br><br><br><br><br>
<br></div>