Lots of feedback from Alfman in the previous article’s comments meant that it was time for another version of my article on my RPC-based daemon model, and as such another iteration towards a final design of my OS’ core IPC mechanism. Not a full rewrite this time, but rather incremental improvements on specific points, which include a choice of naming (nonblocking RPC it is), an improved coverage of pointers, shared memory, and the currently envisioned design limits of those, and explicit support for dynamic setup of RPC calls and graceful server death handling.
Sing# messaging
1/Does it work with any programming language, or only with managed code ?
2/Is it pure message passing, or does it have some kind of optimization for remote calls ?
Edited 2011-06-12 12:17 UTC
I read the paper a bit and noted that you talked about function pointers in the server.
I’d think about taking a page from Windows and use indexes instead of pointers. Have the server publish an array of function pointers. Callers call “Function 0x1d” and not “Function 0x20fcda00”.
To get fancy you can have a dynamic linker do the base + index addition once at load time.
To get fancier, you can have the function array structure encode the number of arguments, required arguments and default values. You could even store the function’s name in there, if you were happy to use a limited size function name.
Hmmm. Actually, the way I currently see it, function pointers are not part of the core design anymore.
You just have an integer which uniquely identifies the call. But that integer may be everything. A pointer, an array index… It’s just a number which the process uses to make a remote call in a known direction. What the number exactly is is left at the kernel’s discretion, although I’d like to reserve identifier 0 for “invalid” calls.
However, you’re right that having the server publish function names and prototypes in batches (using an array) would be faster than having it send it one by one, as it would require only one syscall. Have to investigate this.
Edited 2011-06-13 18:38 UTC
You could use 0 as the equivalent of COM’s IUnknown. It could be the function that returns the list of exported functions.
I have to think more about your array idea… There’s indeed potential to make the interface simpler, but I’m too tired to work on it today.
I’ve had some time to think.
The idea which I had was that clients could send their interface prototypes in an array, too, so that the kernel checks everything versus the server and set up things once, and then all the rest is just calls.
But thinking about it, it’s not necessarily worth it.
1/I’ll still need dynamic RPC setup, because of things like notifications. So I can’t simplify the design a lot by doing this.
2/It’d bring significantly improved performance in case the server has lots of remote calls and the client uses most of them, which seems unlikely. In other situations, the benefit is smaller.