| ▲ | lifis 4 hours ago | |
"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should" It's very cool, but would only be useful in some marginal cases, specifically if you don't want to modify the programs significantly and the reliability reduction is worth either the limited performance upside of avoiding mm switches or the ability to do somewhat easier shared memory. Generally this problem would be better solved in either of these ways: 1. Recompile the modules as shared libraries (or statically link them together) and run them with a custom host program. This has less memory waste and faster startup. 2. Have processes that share memory via explicit shared memory mechanisms. This is more reliable. | ||
| ▲ | jer-irl 3 hours ago | parent [-] | |
Thanks! The idea of launching additional components nearly "natively" from the shell was compelling to me early on, but I agree that shared libraries with a more opinionated "host program" is probably a more practical approach. Explicit shared memory regions is definitely the standard for this sort of a problem if you desire isolated address spaces. One area I want to explore further is using allocation/allocators that are aware of explicit shared memory regions, and perhaps ensuring that the regions get mmap'd to the same virtual address in all participants. | ||