On Monday, 20 January 2014 at 20:11:33 UTC, Tobias Pankrath wrote:
The point is: for true isolation you'll need another process. If you are aware that it could die: let it be. Just restart it or throw the file away or whatever.
That is not an option. I started looking at D in early 2006 because I was looking for a language to create an experimental virtual world server. C++ is out of the question because of all the deficiencies (except for some simulation parts that have to be bug-free) and D could have been a good fit.
Forking is too slow and tedious. File loading was just an example. The "isolate" should have read access to global state (measured in gigabytes), but not write access.
If you cannot have "probable" isolates in safe D, then it is not suitable for "application level" server designs that undergo evolutionary development. I am not expecting true isolates, but "probable". Meaning: the system is more likely to go down for some other reason than a leaky isolate.
Isolates and futures are also very simple and powerful abstractions for getting multi-threading in web services in a trouble free manner.
So given true isolation hlt on null ptr dereference isn't an issue.
You don't need hardware isolation to do this in a way that works in practice. It should be sufficient to do static analysis and get a list of trouble areas which you can inspect.
