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