Workaround for typeid access violation

Etienne via Digitalmars-d digitalmars-d at puremagic.com
Thu Jun 18 07:17:56 PDT 2015


On Thursday, 18 June 2015 at 14:11:42 UTC, ketmar wrote:
> On Thu, 18 Jun 2015 12:08:10 +0000, Etienne Cimon wrote:
>
>> On Thursday, 18 June 2015 at 11:43:18 UTC, ketmar wrote:
>>> On Wed, 17 Jun 2015 22:35:12 +0000, Etienne Cimon wrote:
>>>
>>>> e.g. __gshared MyObj g_obj1;
>>>> 
>>>> Thread 1: g_obj1 = new MyObj;
>>>> Thread 2: g_obj1.obj2 = new MyObj;
>>>> Thread 3: write(g_obj1.obj2); <-- access violation (probably)
>>>
>>> so no way to anchor the whole object tree by assigning it to 
>>> __gshared root? sure, this will never make it into mainline.
>> 
>> __gshared is a little sketchy. We can have TLS GC by default 
>> by piping `new shared` to a shared GC. It's even safer, 
>> because then we have the type system helping out.
>> 
>> e.g. shared MyObj g_obj1;
>> Thread 1: g_obj1 = new shared MyObj;
>> Thread 2: g_obj1.obj2 = new shared MyObj;
>> Thread 3: write(g_obj1.obj2); <-- success!
>
> besides, wouldn't it break `std.concurrency`? (ketmar have to 
> dig into code instead of asking...)

If it does, we fix it. I've never seen druntime/phobos mismatched 
versions (2.067 & 2.066) compiled together successfully, we 
shouldn't allow a necessary change to be blocked because of this 
alone.

As a workaround, you can also do __gshared MyObj g_obj1 = cast() 
new shared MyObj;


More information about the Digitalmars-d mailing list