On 03/10/2014 19:20, Sean Kelly wrote:
On Friday, 3 October 2014 at 17:38:40 UTC, Brad Roberts via
Digitalmars-d wrote:
The part of Walter's point that is either deliberately overlooked or
somewhat misunderstood here is the notion of a fault domain. In a
typical unix or windows based environment, it's a process. A fault
within the process yields the aborting of the process but not all
processes. Erlang introduces within it's execution model a concept of
a process within the higher level notion of the os level process.
Within the erlang runtime it's individual processes run independently
and can each fail independently. The erlang runtime guarantees a
higher level of separation than a typical threaded java or c++
application. An error within the erlang runtime itself would
justifiably cause the entire system to be halted. Just as within an
airplane, to use Walter's favorite analogy, the seat entertainment
system is physically and logically separated from flight control
systems thus a fault within the former has no impact on the latter.
Yep. And I think it's a fair assertion that the default fault
domain in a D program is at the process level, since D is not
inherently memory safe. But I don't think the language should
necessarily make that assertion to the degree that no other
definition is possible.
Yes to Brad, and then yes to Sean. That nailed the point.
To that I would only add that, when encountering a fault in a process,
even an estimation (that is, not a 100% certainty) that such fault only
affects a certain domain of the process, that would still be useful to
certain kinds of systems and applications.
I don't think memory-safety is at the core of the issue. Java is
memory-safe, yet if you encounter a null pointer exception, you're still
not sure if your whole application is now in an unusable state, or if
the NPE was just confined to say, the operation the user just tried to
do, or some other component of the application. There are no guarantees.
--
Bruno Medeiros
https://twitter.com/brunodomedeiros
