On 11/9/2014 1:12 PM, Dicebot wrote:
On Monday, 3 November 2014 at 03:29:05 UTC, Walter Bright wrote:
It is absolutely different because of scale; having 1K of shared memory is
very different from having 100Mb shared between processes including the stack
and program code.
It is possible to have minimal amount shared mutable memory inside one process.
D's type system tries to minimize it, but the generated code knows nothing at
all about the difference between local and shared memory, and has no protection
against crossing the boundary. Interprocess protection is done via the hardware.
There is nothing inherently blocking one to do so, same as there is nothing
inherently preventing one to screw the inter-process shared memory. Being
different only because of scale -> not really different.
Sharing 1K of interprocess memory is one millionth of the vulnerability surface
of a 1G multithreaded program.
What is huge advance for user land applciation is a problem for server code.
Have you ever heard "OS is the problem, not solution" slogan that is slowly
becoming more popular in high load networking world?
No, but my focus is what D can provide, not what the OS can provide.
Preventing cleanup can be done with roughly one line of code from user code.
Enabling it back is effectively impossible. With this decision you don't trade
safer default for more dangerous default - you trade configurable default for
unavoidable.
To preserve same safe defaults you could define all thrown Errors to result in
plain HLT / abort call with possibility to define user handler that actually
throws. That would have addressed all concernc nicely while still not making
life of those who want cleanup harder.
There is already a cleanup solution - use enforce().
That's correct, but not a justification for making it less reliable.
It is justification for making it more configurable.
In general, some things shouldn't be configurable. For example, one cannot mix
3rd party libraries when each one is trying to customize global behavior.
My personal perfect design would be like this:
- Exceptions work as they do now
- Errors work the same way as exceptions but don't get caught by
catch(Exception)
- assert does not throw Error but simply aborts the program (configurable with
druntime callback)
- define "die" which is effectively "assert(false)"
- tests don't use assert
Having assert() not throw Error would be a reasonable design choice.
