Cliff,
Again definitely appreciate the responses. I think my last post might have been a bit confusing in what I was trying to get across. I was using the word core instead of kernel. I suppose I am thinking of a system as follows:
[kernel] [1]<---->
1 kernel to many modules, generally the modules would work on their own name spaces. If a module needed to talk to another module, it would dispatch a message to the kernel which would then forward it to all modules. So system level messages vs module level messages. I suppose a system such as this could be implemented on top of pipes, though with the tee splits you would have no need to have the kernel in between the module to module notifications. I suppose pipes is more robust than an implementation like this because it allows modules to create their own tree structure and possibly internal pipe loops, like multistage filters.
I can understand pipes in the context of passing the output of one application to the input of another application and so on. Very useful if you want to filter messages through another module before it actually gets to the kernel, or if you don't want to bother any other modules and just pass the output to the input of that module.
I guess my question: Is there a lot of applications that use a different tree structure model than the kernel and many cores for a multi core implementation? Is there a lot of architectures that call for in messages and out messages to be processed by different modules? Usual scenarios I can see for a typical application:
1. Module asks Kernel for something (possibly to application config, or possibly reposition the module)
2. Module tells another module(s) to do something (possibly display a new view with the message data)
3. Kernel tells module(s) to do something (possibly refresh)
Again, appreciate the response, just trying to familiarize myself more with the reasoning for when and why I would use pipes and process input and output differently. Or is this just a design choice (as bidirectional setups can be built on this).
Thanks,
-Jason