On Friday, 7 February 2014 at 15:48:56 UTC, Adam D. Ruppe wrote:
> It could also make a copy at that time on to the regular GC heap and store that

lol just add in a quick call to .toGC when you want to store it:

T toGC(T)(T t) if(is(T==class)) {
    auto size = typeid(t).init.length;
    import core.memory;
    auto ptr = GC.malloc(size);
    ptr[0 .. size] = (cast(void*) t)[0 .. size];
    return cast(T) ptr;
}

On 2/6/14, 7:27 PM, Adam D. Ruppe wrote:
> On Friday, 7 February 2014 at 03:14:45 UTC, Sean Kelly wrote:
>> On Thursday, 6 February 2014 at 22:20:38 UTC, Dicebot wrote:
>>> UTFException if str is not well-formed.
>>
>> unbelievable abomination of a function design.
>
> Yeah, that is absurd. It is a bad, bad sign when almost every time you
> use a function, you write
>
> bool ok = true;
> try validate(s); catch(UTFException) ok = false;
> if(!ok) {}
>
> yet that's how i use validate...

Add a bugzilla and let's define isValid that returns bool!

Andrei

On Friday, 7 February 2014 at 16:27:35 UTC, Andrei Alexandrescu wrote:
> Add a bugzilla and let's define isValid that returns bool!

Add std.utf.decode() to that as well. IOW, it should have an overload which returns a status code but assigns the return value through another parameter.

07-Feb-2014 06:44, Walter Bright пишет:
> On 2/6/2014 2:15 PM, Brad Anderson wrote:
>> Personally I don't think bad user input qualifies as an exceptional
>> case because
>> it's expected to happen and the program is expected to handle it (and
>> let the
>> user know) when it does. That's just a matter of taste though.
>
> It's not a matter of taste. If your input is subject to a DoS attack,
> don't put exceptions in the control flow.

Meh. If exceptions are such a liability we'd better make them (much) faster.

-- 
Dmitry Olshansky

07-Feb-2014 20:29, Andrej Mitrovic пишет:
> On Friday, 7 February 2014 at 16:27:35 UTC, Andrei Alexandrescu wrote:
>> Add a bugzilla and let's define isValid that returns bool!
>
> Add std.utf.decode() to that as well. IOW, it should have an overload
> which returns a status code

Much simpler - it returns a special dchar to designate bad encoding. And there is one defined by Unicode spec.


-- 
Dmitry Olshansky

On Friday, 7 February 2014 at 16:41:00 UTC, Dmitry Olshansky wrote:
>
> Meh. If exceptions are such a liability we'd better make them (much) faster.

It's not stack unwinding speed that's an issue here though, but rather that for client-facing services, throwing an exception when an invalid request is received gives malicious clients an opportunity to hurt service performance by flooding it with invalid requests.  Improving the exception code specifically doesn't help here because the real issue is with GC collections.  I'd say that the real fix is for such services to simply not throw in this case.  But the exception could always be recycled as well (since in this case you know that throwing will abort the transaction and so will always be immediately discarded).  I'm not convinced that there's any need for a language change here to support scoped exceptions.  That seems a bit like killing the ant with a steamroller.

07-Feb-2014 20:49, Sean Kelly пишет:
> On Friday, 7 February 2014 at 16:41:00 UTC, Dmitry Olshansky wrote:
>>
>> Meh. If exceptions are such a liability we'd better make them (much)
>> faster.
>
> It's not stack unwinding speed that's an issue here though, but rather
> that for client-facing services, throwing an exception when an invalid
> request is received gives malicious clients an opportunity to hurt
> service performance by flooding it with invalid requests.

Why throwing a single exception is such a big problem? Surely even C's long_jump wasn't that expensive? *Maybe* we shouldn't re-construct  full stack trace on every throw?

> Improving the
> exception code specifically doesn't help here because the real issue is
> with GC collections.

Then the problem is that something so temporary as an exception is allocated on the GC heap in the first place? Let's go for something more sane and deprecate the current behavior, it's not like we are forever stuck with it.

>I'd say that the real fix is for such services to
> simply not throw in this case.  But the exception could always be
> recycled as well (since in this case you know that throwing will abort
> the transaction and so will always be immediately discarded).

Exceptions are convenient and they make life that much easier combined with ctors/dtors and scoped lifetime. And then we say **ck it - for busy services, just use good ol':
...
if (check42(...) == -1){ call_cleanup42(); return -1; }
...

And up the callstack we march. The moment code gets non-trivial there come exceptions and RAII to save the day, I don't see how busy REST services are unlike anything else.

> I'm not
> convinced that there's any need for a language change here to support
> scoped exceptions.  That seems a bit like killing the ant with a
> steamroller.

Well I'm not convinced we should accept that exceptions are many times slower then error codes (with checks on every function that may fail + propagating up the stack).

-- 
Dmitry Olshansky

On 2/7/14, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
> Much simpler - it returns a special dchar to designate bad encoding. And there is one defined by Unicode spec.

A NaN for chars? Sounds great to me! :)

On Friday, 7 February 2014 at 15:33:01 UTC, Adam D. Ruppe wrote:
> One problem with allocating the exception is the stop-the-world thing.

Ok, well I guess that primarily is an issue for validation errors where you need to return detailed error reporting. "Not Found" etc can be preallocated as immutable, or?

> constructor, which is run once per request. It can answer requests at a rate of about 6000/sec on my computer...

That sounds pretty good, was that as localhost, or over a network?

> (BTW, interestingly, on Linux it uses separate process pools instead of threads. The GC does NOT stop the world since the other processes can keep going. But, if the requests are fairly uniform - as is typically the case with benchmarks - each process hits the GC threshold at about the same time.... ironically, it is the deterministic nature of the GC that leads to the performance killer there.)

You could synchronize them by calling the GC explicitly N seconds after the other process GC or you if you use a load balancer, maybe the GC could be scheduled by the load balancer or notify the load balancer (assuming all requests are short-lived).

This won't work for a simulation type server though. (which is what I am most interested in)

On Friday, 7 February 2014 at 17:06:36 UTC, Dmitry Olshansky wrote:
>> I'm not
>> convinced that there's any need for a language change here to support
>> scoped exceptions.  That seems a bit like killing the ant with a
>> steamroller.
>
> Well I'm not convinced we should accept that exceptions are many times slower then error codes (with checks on every function that may fail + propagating up the stack).

As I have already mentioned, they don't necessarily need to be. But that may require tweaking language so that pre-allocated exception usage becomes reliable and I don't see tools right now that allow to express neseccary semantics (can't store reference to instance without deep copy)