On Tuesday, 13 January 2015 at 23:58:53 UTC, deadalnix wrote:
http://dlang.org/phobos/core_thread.html#.Thread.join
I don't see the problem. I'm suggesting value semantics, it can
be copied.
When you are in the catch, you are not unwinding anymore. You
could indeed loose chaining to be able to reuse the memory,
that is not what is slow when it come to exception, so it won't
make it fast.
You can't have chaining with this scheme...? But since you can
only have one instance it has to be initialized with value
semantics. It's a small constraint.
Not using regular Itanium-style unwinding will make it
potentially faster. Using TLS makes it possible to propagate over
non-D code or code where the register pressure is high, it can be
optimized away so you don't need TLS if you don't span over non-D
code.
1. So that you can mark a non-D function with @checkexception
and allow it to both cast D-exceptions and propagate
D-exceptions.
Empty hand waving, not not addressing the point.
Who are you waving at?
Non D functions can cast by setting the TLS memory to an
exception value, then do a regular return. The D function that
called the non-D function will check TLS memory to see if there
is an exception in flight.
Skipping 4 and 5, you obviously didn't though that through.
?
What you propose in point 1 - 3 is weak at best. You haven't
put serious effort thinking about what you are proposing, so
there is no reason anyone should spend any serious effort
criticizing it.
Then don't bother.
If your point regarding point 4 was that it would limit cross
compiler linking, then yes. And that would be intentional, since
it is far too soon to standardize D at that level. It just
prevents experimentation and performance gains.
If your point regarding point 5 is that it would be too limiting,
well then you would need to differentiate between D and C
entrypoints to D functions to overcome the problem. That's
possible, but IMO not worth it.
