Using static immutable Exceptions (or other way for NON-GC exceptions)

[Iain Buclaw via D.gnu]

On 18 February 2015 at 13:38, Timo Sintonen via D.gnu
<d.gnu at puremagic.com> wrote:
> On Wednesday, 18 February 2015 at 13:07:12 UTC, Iain Buclaw wrote:
>>
>> On 18 February 2015 at 12:34, Timo Sintonen via D.gnu
>> <d.gnu at puremagic.com> wrote:
>>>
>>> On Wednesday, 18 February 2015 at 12:12:04 UTC, Iain Buclaw wrote:
>>>
>>>>
>>>> You can't throw without a GC allocation currently.  I'm open to
>>>> suggestions and patches welcome.
>>>>
>>>> See here:
>>>>
>>>> https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/deh.d#L152
>>>>
>>>>
>>>> Iain.
>>>
>>>
>>>
>>> I was just goimg to ask about the state of this.
>>> I have understood that this struct carries all the necessary info trough
>>> unwinding and it is not freed until gc frees it.
>>> Where is the last place this struct is used. Is it in druntime side or in
>>> libgcc side?
>>
>>
>> The last place it is used is on the libgcc side, or at least the
>> generic exception header that our language-dependent header holds.
>>
>> It may be a better solution to have a static TLS pointer that gets
>> new'd upon thread start.  Perhaps even make it a pre-allocated array
>> so we might be able to get chained exceptions working in GDC runtime.
>>
>>> Could it be possible to allocate this with malloc and free after
>>> unwinding?
>>> I have understood that this struct is not available any more in catch
>>> block.
>>> Do we need many copies of this. Could it be possible to have a static
>>> one?
>>
>>
>> See __gdc_exception_cleanup just above _d_throw.  We use destroy(p) in
>> the cleanup.  It could work to swap 'destroy' with 'free', and 'new'
>> with 'calloc'.  But that still doesn't help if we are throwing an
>> OutOfMemory exception.  It will still fail hard, rather than bail with
>> a nice backtrace.
>>
>> Iain
>
>
> Out Of Memory is a special case and usually a fatal case. There was some
> discussions lately about this but I did not follow it.
> If OutOfMemory is not working anyway then we do not loose anything? We may
> get the other exceptions to work. So why not make this until we find out
> some better solution?
>

Regardless, "Out of Memory" is a more informative message than
"Segmentation Fault".   Especially so if you are the one trying to
debug the program.  And find the 'trigger'.  :-)

Iain