3 ms·
So you go from distinguishing between processes on the language and OS levels, to categorically declaring you can't share memory implicitly with processes. A f
by nknight 15y ago
So you go from distinguishing between processes on the language and OS levels, to categorically declaring you can't share memory implicitly with processes.
A facsimile of a process that isn't implemented as an actual process is going to be in a shared address space. Your pet bondage-and-discipline language might work to prevent one pseudo-process from interfering with another, but I don't see it being equal to full-blown processes, nor do I see it being substantively more trustworthy than making a few simple, easy decisions about how to structure your programs.
- masklinn 15y ago> categorically declaring you can't share memory implicitly with processes. That's kind-of the whole point, and difference between threads and processes. If you have implicitly shared mutable memory with processes, your processes are broken and you have threads. > I don't see it being equal to full-blown processes Really? > nor do I see it being substantively more trustworthy That's interesting. So you don't see how the language enforcing a share-less discipline would be more trustworthy than people trying to do so informally? > than making a few simple, easy decisions about how to structure your programs. Such as not using any third-party code which has not been fully audited to the statement? What a simple and easy decision that is.