@Schol-R-Lea: Cool, thanks!
AndrewAPrice wrote:
eekee wrote:
with a safe language, you don't need an MMU, and without an MMU, IPC can be a function call.
There are a lot of implementation details we'd need to figure out if we want to do function calls between processes.
That is true. "Just" passing a pointer or calling a function should to the speed of the operation more than any simplification, (I should try to remember that,) but some simplifications do arise.
AndrewAPrice wrote:
Can you share memory between processes? (Let's say I allocate a class in Process A, can Process B access it and call methods on it?)
Without any memory protection, the answer here is easy: Yes! With simple memory protection the kernel needs to allow it, but only that. There's no need to translate addresses.
AndrewAPrice wrote:
How do you determine what process owns a chunk of memory?
Good question. One answer would be to mark them both as owners. Perhaps the original owner tells the kernel to grant co-ownership to another process. Or perhaps the original owner retains ownership, and the other is notified if the original owner exits. I momentarily thought the latter would also require informing the kernel of the connection, but then I thought a process could maintain its own list of processes which need to be notified when it exits. That's probably too loose if a kernel call is just a function call.
AndrewAPrice wrote:
If ownership of objects can be moved, could a malicious program keep calling a critical service with a large payload?
Uh.... what does moving ownership have to do with a typical DoS attack?
AndrewAPrice wrote:
How do you handle terminating processes? (E.g. Imagine Process A calls Process B which calls Process C, but B terminates while C is still doing something. What will happen when C returns?)
What happens if Process A implements an interface, sends the object to Process B, then A terminates, and B tries to call a virtual method on the interface?
I don't see a difference between these two; both being a case of a depended-upon process terminating. Good call anyway. Looks like it'll need a notification (signalling) system.
AndrewAPrice wrote:
What happens if Process A is updated and the exported function's signature changes, but Process B is a commercial closed source application and the developers haven't rebuilt it for the newer API, and it tries to call Process A with the wrong function signature?
This isn't IPC-specific at all, but is in fact the issue which annoys me the most in all of computing. It's everywhere and practically impossible to get rid of! It applies to any dependancy of one package on another, even if the dependency is on a shell script. (Remember prototypes only provide a means to check an interface. Problems with the interface changing occur regardless of how well-checked it is. In fact, they're more annoying if it isn't well-checked.) Here's an excellent article on it:
Our Software Dependency Problem. The article talks about risk, but part of the risk with any depency is the cost of its interface changing. (I think the article mentions this, but it's been a while since I read it carefully.) I know APIs have to change sometimes, but with my fatigue issues, I'm inclined to view developers who horse around with their API all the time as little better than malicious hackers anyway.
This includes developers who release without planning well, then have to make a lot of changes. In the past, I've declared, "I've
really had enough of my time being wasted by this!" All the same, the problem is hard to get rid of because, no matter how carefully you plan, releasing is necessary to find bugs.