'importing' threads — i.e. thread_attachThis()

[Guillaume Piolat via Digitalmars-d-learn]

On Friday, 12 August 2016 at 10:45:22 UTC, Cauterite wrote:
>
> - Would having an entry function other than 
> core.thread.thread_entryPoint() pose problems?

No.


> What about during stack unwinding?

It doesn't need runtime or attachment.

> Should I try to replicate the exception handling code of 
> thread_entryPoint() in my own entry function?

If you control the whole lifetime of the thread, probably so.

> - I'm aware of having to invoke rt_moduleTlsCtor() explicitly, 
> but what about rt_moduleTlsDtor() ? Should I again follow 
> thread_entryPoint()'s behaviour here?

Same answer.
Two cases: you create and destroy the threads (which seem to be 
your case) or you just get callbacks.

> - How important is it to run the thread though _beginthreadex() 
> ? I know the Microsoft CRT uses 
> _beginthreadex()/_threadstartex() to set up the thread's 
> '_tiddata' object, but since D uses the Digital Mars 
> _beginthreadex (which I don't have source for) I'm not entirely 
> sure what goes on in there. It *appears* to be messing around 
> with a global '__thdtbl' object.

In Windows circle I've heard that beginthreadex was necessary but 
I don't remember why.

> - Do I need to call thread_detachThis() when the thread 
> terminates, or can I just wait until the corresponding Thread 
> object gets destroyed by the GC?

- Whole lifetime case:
You don't necessarily need to. When the runtime terminate 
(Runtime.terminate()) every thread will be detached.

- Callback case:
You may have problems if one of the registered thread is 
destroyed outside of your program and then the GC tries to stop 
it though. For this reason if you are in the callback case you 
can try to detach it on exit.