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