Non-null objects, the Null Object pattern, and T.init

Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com> Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Mon Jan 20 13:35:55 PST 2014


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.


More information about the Digitalmars-d mailing list