I have something along this way:

struct json_value
{
	..
}

function DoDirSearch(..)
{
	immutable json_value cbk = json_value(prms.argv[3]);
	assert(cbk != json_value.init); // OK, pass
	
	import core.thread;
	new Thread({
		assert(cbk != json_value.init); // FAIL!
	}).start();
}

the problem is, my struct value is not saved in the spawned tread context, so this assert fails while at the start it passed:

assert(cbk != json_value.init);

mmm, I figured the problem, but don't know how to solve it.
my struct has a destructor which clears itself:

struct json_value
{
  ~this() { .ValueClear(&data); }
}

so how I can I put a struct in the heap? (not in the stack, as is the default..)

On Saturday, 23 April 2016 at 01:11:49 UTC, Ramon wrote:
> mmm, I figured the problem, but don't know how to solve it.
> my struct has a destructor which clears itself:
>
> struct json_value
> {
>   ~this() { .ValueClear(&data); }
> }
>
> so how I can I put a struct in the heap? (not in the stack, as is the default..)

new or make with arg or new or make then opAssign or this(this).

but have you tried

    __ghsared immutable json_value cbk = json_value(prms.argv[3]);

? without __gshared cbk might be on the TLS. (see with -vtls switch on DMD)

On 23.04.2016 03:11, Ramon wrote:
> mmm, I figured the problem, but don't know how to solve it.
> my struct has a destructor which clears itself:
>
> struct json_value
> {
>    ~this() { .ValueClear(&data); }
> }

So the struct is destroyed at the end of DoDirSearch, despite there being a closure for it. Is the compiler doing the right thing here? Shouldn't the struct be considered alive until the closure gets garbage collected?

On 23.04.2016 07:35, ag0aep6g wrote:
> So the struct is destroyed at the end of DoDirSearch, despite there
> being a closure for it. Is the compiler doing the right thing here?
> Shouldn't the struct be considered alive until the closure gets garbage
> collected?

I've filed an issue:
https://issues.dlang.org/show_bug.cgi?id=15952