On Wednesday, 5 April 2017 at 16:08:33 UTC, David Nadlinger wrote:
> On Wednesday, 5 April 2017 at 14:35:18 UTC, Guillaume Piolat wrote:
>> But those of us with the runtime disabled don't have TLS.
>
> This is only true on DMD/OS X x86, where TLS is emulated in druntime. On other platforms, TLS is implemented by the linker and/or C runtime, so it works without druntime just fine.
>

TIL, thanks.

> Regular thread-local module constructors (static this) of course won't work without druntime support, as they are mediated through ModuleInfo.
>
>  — David

Sure.
This means TLS is here but uninitialized and eg. core.cpuid has to be duplicated.
Fragmentation ensues.

On Wednesday, 5 April 2017 at 16:33:42 UTC, Guillaume Piolat wrote:
> This means TLS is here but uninitialized and eg. core.cpuid has to be duplicated.
> Fragmentation ensues.

You can still lazily initialise TLS data, though. — David

On Wednesday, 5 April 2017 at 14:35:18 UTC, Guillaume Piolat wrote:
> But those of us with the runtime disabled don't have TLS.
> throwing, .destroy, TLS (and static this) are the fragmenting factors between runtime-free and D normal D.

I'm going to be harsh here and say that the D team members should focus on it's users who are using druntime + Phobos and allow people to use their own runtime if they wish. Then for the most part, ignore everyone else. We cannot afford to make concessions to a small handful of our userbase with our limited dev time.

Suggested party line: if you don't want to use druntime, best of luck, you're on your own. We're not going to gimp Phobos for you.

On Wednesday, 5 April 2017 at 09:51:16 UTC, Walter Bright wrote:
> Much of Phobos has been redone to not assume/require the GC. A glaring exception (!) is when Exceptions are thrown, which is why we're looking for a solution.

Make the exception owned, and let the caller decide.

On Monday, 3 April 2017 at 23:33:10 UTC, Jack Stouffer wrote:
> Example: company wants to use their custom GC (like sociomantic) with Phobos. They want to do this even for exceptions because they believe that things will be faster if they're able to completely control when any memory is freed. Your solution does not help these people use Phobos because the compiler will be inserting calls to free in places they don't want, which will slow down their program.

I think that because of that, the following should be possible:

Exception store;
catch(Exception e)
{   //does not call the destructor
    store = new Exception(e.move);
    //still no destructor called because e is null
}

In case of preallocated exceptions, thats ugly to do everywhere. But it could be argued that so is relying on EH speed on the first place! Form follows the function. Still, I agree that's a problem.

On Wednesday, 5 April 2017 at 16:33:42 UTC, Guillaume Piolat wrote:
> This means TLS is here but uninitialized and eg. core.cpuid has to be duplicated.
> Fragmentation ensues.

Good, it provides options with various tradeoffs that fulfill more needs. If you don't want to have choice, use stock druntime+phobos, that's the way for unification and defaults.

On Wednesday, 5 April 2017 at 17:35:01 UTC, Jack Stouffer wrote:
>
> Suggested party line: if you don't want to use druntime, best of luck, you're on your own. We're not going to gimp Phobos for you.

s/wan't/can't
Avoiding druntime is not done for the fun of it, but because there is (in rare cases granted) no other choices.

On 02/04/17 18:24, Dmitry Olshansky wrote:
> On 4/2/17 9:14 AM, Walter Bright wrote:
>> On 4/1/2017 11:50 PM, Nicholas Wilson wrote:
>>> On Sunday, 2 April 2017 at 05:16:23 UTC, Walter Bright wrote:
>>>> Problem
>>>> =======
>>>>
>>>> [...]
>>>
>>> How will this interact with preallocated exceptions (e.g.  from
>>> Liran's dconf
>>> talk last year)?
>>
>> It will copy them and throw the copy.
>
> Copy means allocate and then deallocate in the catch, defeating the
> whole propose of preallocating. Would it be possible to just set a bit
> somewhere that indicates that the exception is preallocated and need not
> be freed.
>
> So for instance:
>
> throw new Exception; // this is allocated exception
>
> auto e = makeMeAnException();
> throw e; // this is preallocated exception (need not be freed in the catch)
>
> ---
> Dmitry Olshansky

The preallocated exceptions in weka were created as a work around for exceptions requiring GC. If we can throw without invoking the GC, we'll probably be fine with tossing them.

Shachar

On Monday, 3 April 2017 at 21:43:13 UTC, Adam D. Ruppe wrote:
>
> This file shows like 3 concepts I have with exceptions, but the RaisedExceptionDetails.toString shows this:
>
> http://arsdnet.net/exception.d
>
>
> It is an easily solved library problem... and would be *easier* to use than format().

I was going to propose the same thing, thanks for writing it for me!

On 4/6/2017 6:00 AM, Shachar Shemesh wrote:
> The preallocated exceptions in weka were created as a work around for exceptions
> requiring GC. If we can throw without invoking the GC, we'll probably be fine
> with tossing them.
>
> Shachar

That's what I thought. Thanks for the confirmation.