Mill CPU Inter-Process Communication
Overall, this seems like one of the weaker Mill talks. Since they apparently don&#x27;t yet have a real OS running real software in simulation, they probably haven&#x27;t had the ability to test the ideas that affect how software is structured at a higher level.<p>They don&#x27;t provide nearly enough ways to transitively grant permissions. Using the mechanisms discussed in the talk, it doesn&#x27;t seem like you can implement a simple asynchronous queue of units of work to perform, each having their own permissions. The belt architecture encourages these sorts of second-class mechanisms that have to be used in a rigid way, because the details can be hidden in the belt and not be exposed architecturally.<p>Unless there&#x27;s something else not mentioned in the talk, it seems like you still need to trust the OS, because when the OS is asked to allocate a page for a spillet there is nothing stopping it from creating a virtual alias of that page elsewhere and allowing another thread to read its data.<p>The mechanism to support fork() is a total kludge. Why have a single address space if you&#x27;re just going to add segmentation in such an ad-hoc way for a single use case? Just run the original binary in emulation until exec() or something like that.