Question about HXCPP GC

[Joshua Granick]

Hello,

I was wondering if anyone knew the answer to a few GC questions

 1.) Is it safe to allocate in a Haxe thread?

 2.) When using `val_call` from native code, do you need to do anything special to prevent GC issues ("set top of stack", etc?)

 3.) What about allocations from CFFI, while running in a different thread? Anything special?

I am experiencing crashes in the GC mark phase, wondering how this should work :)

Thanks!

[Hugh]

1) Certainly - unless you have entered a GC free zone

2) val_call will probably make GC calls, either directly when passing args, or indirectly inside the callback, so the native thread will need to be attached to the GC system.

  For a native thread, this is done with the set_top_of_stack(&data,true), set_top_of_stack(0,true) pair surrounding the val_call.

3) Same applies to any cffi calls - the threads will need to be attached for the duration of making calls.

  Also note that things like arrays and maps are not thread-safe, so if your callback touches these, you will need a mutex.

There are some notes here:

https://github.com/HaxeFoundation/hxcpp/blob/master/docs/ThreadsAndStacks.md

I noticed one issue someone was having with a struct placed in the stack.  

Structs will be scanned for pointers, but if you have  a pointer member you may run into issues:

struct DataStruct

{

   value d;

};

struct SomeStruct

{

   value v;

   DataStruct *data;

};

Here, if you have SomeStruct on the stack, 'v' will be correctly marked, but the data pointer will not be followed, so 'd' will not be marked.

If you define "-D HXCPP_GC_CHECK_POINTER" when you compile, there are some additional checks that may fire when you try to use an object that escaped marking.

This can happen earlier, so it is better than crashing in the mark phase, and can give a hint about which object needs fixing.

Hugh