Jiri,
Not quite. For example in the case of PCI device driver, where one instance of the driver can be the child of another instance, two fibrils in the 'pci' task will communicate.
Yes, of course. I have never written that such situation is forbidden or something. If the run-time (dynamic) composition of the communicating parties leads to such a situation where one thread/fibril of one task happens to communicate with a different thread/fibril of the same task via IPC, then it just works.
But I believe that this is not a typical way you would explicitly design a static software architecture. Neither do you use RPC or TCP streams all the time in an UNIX application if you know that the parts of the application are designed to be used locally. You just use plain function calls and local sockets in that case. And yes, it might happen at run-time that you sometimes call local functions over RPC and that you send data over TCP to localhost. But it is a corner case.
My suggestion for Tobias was merely to focus on the more typical scenario for IPC his test case: Two distinct tasks communicating over IPC.
I remember no special provisions in the async framework had to be done to make this work.
I agree. M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
