I have a DLL written in D that gets called by two different threads, created by a non-D host program (audio plugin). I did not create those threads, but my understanding is that they get "attached" to the D runtime.

Thread A is a real-time callback and should not ever block. @nogc seems perfect for this.

Thread B and it's impractical to make it @nogc.

How to ensure that a collection triggered by thread B never stop thread A in stop the world collections?

On Wednesday, 3 December 2014 at 22:53:48 UTC, ponce wrote:
> I have a DLL written in D that gets called by two different threads, created by a non-D host program (audio plugin). I did not create those threads, but my understanding is that they get "attached" to the D runtime.
>
> Thread A is a real-time callback and should not ever block. @nogc seems perfect for this.
>
> Thread B and it's impractical to make it @nogc.
>
> How to ensure that a collection triggered by thread B never stop thread A in stop the world collections?

Correction:

> Thread B isn't real-time, allocates, and it's impractical to make it @nogc.

On Wednesday, 3 December 2014 at 22:53:48 UTC, ponce wrote:
> I have a DLL written in D that gets called by two different threads, created by a non-D host program (audio plugin). I did not create those threads, but my understanding is that they get "attached" to the D runtime.
>
> Thread A is a real-time callback and should not ever block. @nogc seems perfect for this.
>
> Thread B and it's impractical to make it @nogc.
>
> How to ensure that a collection triggered by thread B never stop thread A in stop the world collections?

I assume you are referring to Windows and I have no good answer for you. Could it not vary between implementations or is it language defined? However, a real time thread ought to be specified by the OS as being non-interruptable (but with a timeout). Otherwise it should not be labeled as realtime… AudioUnits on OS-X are called with realtime priority.

IRRC the D GC uses SIGUSR1 on unix, so there you should be able to specify a signal mask to tell the OS whether to block the thread on collection or not.

On Thursday, 4 December 2014 at 00:27:49 UTC, Ola Fosheim Grøstad wrote:
> I assume you are referring to Windows and I have no good answer

Btw, I found this page to be a nice starting point and generally a good read for writing portable code:

http://msdn.microsoft.com/en-us/library/ms811896.aspx

On Thursday, 4 December 2014 at 00:27:49 UTC, Ola Fosheim Grøstad wrote:
> IRRC the D GC uses SIGUSR1 on unix, so there you should be able

Hmmm, I have no idea why I wrote this. According to the code for the runtime it only suspends threads that inherit from Thread? GC fullcollect calls thread_suspendAll which traverses a linked list of Threads.

So I suppose none of your threads are suspended unless you suspend it with Thread on call_back entry? But why suspend a @nogc thread?

https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d#L2501

https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L2479

On Thursday, 4 December 2014 at 01:36:13 UTC, Ola Fosheim Grøstad wrote:
> So I suppose none of your threads are suspended unless you suspend it with Thread on call_back entry? But why suspend a @nogc thread?

What a mess of incorrect recollection and typos (it is late, 3AM :-P): I  meant to say that I suppose none of your threads are suspended unless you register it as a Thread before the call_back entry. But if you do it on the call_back entry point by registering a fake Thread object you must ensure that you are not already in a collection cycle before continuing…

Seems to me that there should either be better documentation of GC behaviour or some extra functionality for controlling GC interference with threads and Threads. I also find this confusing… There is a lot of policy making in D's runtime and standard library.

On 2014-12-03 23:53, ponce wrote:
> I have a DLL written in D that gets called by two different threads,
> created by a non-D host program (audio plugin). I did not create those
> threads, but my understanding is that they get "attached" to the D runtime.

No, the runtime in D doesn't know anything about threads created outside of D, unless you explicitly register them with the runtime.

-- 
/Jacob Carlborg

On Thursday, 4 December 2014 at 02:01:26 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 4 December 2014 at 01:36:13 UTC, Ola Fosheim Grøstad wrote:
>> So I suppose none of your threads are suspended unless you suspend it with Thread on call_back entry? But why suspend a @nogc thread?
>
> What a mess of incorrect recollection and typos (it is late, 3AM :-P): I  meant to say that I suppose none of your threads are suspended unless you register it as a Thread

Thanks Ola & Jacob.
In fact I was registering them both with core.sys.windows.dll.dll_thread_attach() when callbacked with DLL_THREAD_ATTACH, but I see now that I should instead register to the runtime only the interruptible thread.

Made-up problem!

On Thursday, 4 December 2014 at 08:18:23 UTC, ponce wrote:
> In fact I was registering them both with core.sys.windows.dll.dll_thread_attach() when callbacked with DLL_THREAD_ATTACH, but I see now that I should instead register to the runtime only the interruptible thread.

Yes, I assume you should still call it for the real time thread, but with the first param set to false?

bool dll_thread_attach( bool attach_thread = true, bool initTls = true )

> Made-up problem!

Made-up problems can be very useful. I got some new ideas for real time GC support when thinking about this… ;-)