On Wed, 03 Dec 2014 02:21:45 +0000 Michael via Digitalmars-d-learn <[email protected]> wrote:
> Thanks for this. Its definitely a step in the right direction. > Would you mind explaining a bit more about the problem here, if > you can? I don't fully understand why the garbage collector needs > to know about the threads, and if so for how long does it need to > know? If I put in > "thread_attachThis();scope(exit)thread_detachThis();" it doesn't > appear to fix my problems, so I'm definitely curious as to what > is going on under the hood. you have to call `thread_attachThis();` in "alien" thread, not in D thread. i.e. if you created thread from python code, you have to call `thread_attachThis();` in that python thread (i don't know how you'll do that, but you must ;-). and you must call `thread_detachThis();` from the same python thread before exiting from it. garbage collector must know about all running threads so it can scan their stacks, variables and so on. as there is no portable way to set application-wide hooks on thread creation and termination, you must inform GC about that events manually. the other thing you can do is to not use any D allocated data in "alien" threads. i.e. don't pass anything that was allocated by D code to python thread and vice versa. if you want to pass some data to "alien" thread, `malloc()` the necessary space, copy data to it and pass malloc'ed pointer. don't forget to free that data in "alien" thread. but i think that this is not what you really want, as it means alot of allocations and copying, and complicates the whole thing alot. "alien" is the thread that was created outside of D code.
signature.asc
Description: PGP signature
