Am 20.02.2014 22:05, schrieb Dicebot:
On Thu, 20 Feb 2014 19:08:46 +0100, Sönke Ludwig wrote:
I definitely think that 2) is the absolute minimum that has to be done
(it would probably even be enough to resolve symbols for the stack trace
lazily). And probably when that is done, there isn't even a real problem
anymore (the 404 case should still be changed).No, it won't be enough, I have made some quick tests with hacked changed druntime. You will never ever be able to use exceptions efficiently if those are allocated (especially if it is GC allocation that can trigger collection).It may not be notable if normal processing code also allocates regularly but than it does not make any sense to speak about performance at all.
You mean GC allocated. Using a free list based allocator for example,
surely is fast enough. What's missing is a way to use manual allocators
for exceptions (safely, more or less).
I think ARC support (with a fast allocator) + lazily formatted exception
messages (using an output sink to write directly to an output range)
would be a way to solve this so that it will be far from being a DDoS
target.
We use exeptions in similar way in some Sociomantic code but both conditions are strictly conformed (custom runtime + always reuse instances). It is natural desire because of convenience but exceptions were never designed for throwing performance (and D spec explicitly warns about it) so you can't get it without making some sacrifices and/or restrictions. Prohibiting storing exception instances (or doing fiber switch inside catch) is smallest such sacrifice that can work.
But that would go completely against the safe API approach. This is
where scope could usually help, but unfortunately this doesn't apply
to the exception context.
An alternative pattern is to use version exceptions to be immutable in release code (with no fancy custom formatting) and costly allocated in debug mode.
In practice most applications don't really care though same as they don't pay much attention to allocations in user code.
Let's just say that the core package should avoid allocated exceptions
as far as possible (event code, HTTP code). The higher level code or the
DB drivers still contain enough allocations that once exceptions aren't
crazily slow anymore, their allocation shouldn't be an issue in
comparison, especially since most of them will indeed occur rarely.
But regardless of what the decision is for the application or framework,
if throwing an exception can be considered a security risk because of
DDoS, then something must be very wrong. Considering that there may be
many places where an exception is thrown in Druntime or Phobos, it would
be a very difficult task to get an application to the point where it
can't throw anymore (or even just to only have it throw pre-allocated
exceptions). You could never be certain.