On 05/31/2017 09:04 AM, Steven Schveighoffer wrote:
I have discovered an annoyance in using vibe.d instead of another web
framework. Simple errors in indexing crash the entire application.
For example:
int[3] arr;
arr[3] = 5;
Compare this to, let's say, a malformed unicode string (exception),
malformed JSON data (exception), file not found (exception), etc.
Technically this is a programming error, and a bug. But memory hasn't
actually been corrupted. The system properly stopped me from corrupting
memory. But my reward is that even though this fiber threw an Error, and
I get an error message in the log showing me the bug, the web server
itself is now out of commission. No other pages can be served. This is
like the equivalent of having a guard rail on a road not only stop you
from going off the cliff but proactively disable your car afterwards to
prevent you from more harm.
This seems like a large penalty for "almost" corrupting memory. No other
web framework I've used crashes the entire web server for such a simple
programming error. And vibe.d has no choice. There is no guarantee the
stack is properly unwound, so it has to accept the characterization of
this is a program-ending error by the D runtime.
I am considering writing a set of array wrappers that throw exceptions
when trying to access out of bounds elements. This comes with its own
set of problems, but at least the web server should continue to run.
What are your thoughts? Have you run into this? If so, how did you solve
it?
This is a meaningful concern. People use threads instead of processes
for serving requests for improving speed and footprint. Threads hardly
communicate with one another so they are virtually independent. D
already has good mechanisms for isolating threads effectively (the
shared qualifier, @safe) so an argument could be made that bringing down
the entire process because a thread has had a problem is
disproportionate response.
This was a concern about using D on the server for Facebook as well.
Of course, it may be the case that that thread's failure reflects a
memory corruption that affects all others, so one could reduce the
matter to this and argue the entire process should be brought down. But
of course things are never as simple as we'd like them to be.
Array bound accesses should be easy to intercept and have them just kill
the current thread. Vibe may want to do that, or allow their users to.
The more difficult matter is null pointer dereferences. I recall there
has been work in druntime to convert memory violations into thrown
Errors at least on Linux. You may want to look into that.
It seems to me we'd do good to improve matters on this front.
Thanks,
Andrei
