I realize a rational knee-jerk response would be "Remoting you idiot! Read the MSDN docs." Every scrap of info I can find concerning .Net Remoting is in the context of inter-process communication: sockets, shared memory, pipes...the classics when it comes to IPC, but an AppDomain is not really a process. However, AppDomains seem to enjoy most of the benefits of being one. From an academic perspective, OS IPC primitives are heavy compared to communication between entities that reside in the same process. Is there a special AppDomain pipe that is used when communication crosses an AppDomain boundary within the same process? I doubt it. I would be shocked if MS changed the fundamentals of process isolation within the Windows kernel to accommodate AppDomains.
views:
325answers:
3What is the underlying mechanism used to communicate between .Net AppDomains in the same process?
There's a fast path in this case. There is no need for interprocess communication, since the appdomains live in the same process and the CLR has full access to all of them and the full address space. It's really just some markers in the call stack for security and exception handling purposes as well as the unloadability that appdomains give.
A side note to your question, or more of a history foot note. This is not entirely new, COM had somewhat similar semantics in marshaling interfaces between threads: one thread would marshal the interface into a stream using CoMarshalInterThreadInterfaceInStream and then the other thread would extract the intrface form the stream using CoGetInterfaceAndReleaseStream.
The fundamental way to communicate between AppDomains within a process is indeed remoting. This allows an object to live in one AppDomain and have others communicate through it via a transparent proxy in another domain.
Yes AppDomains are not really a process but they are best envisioned as very light weight processes.