Re: How to ensure a thread cannot be blocked by the GC?
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
Re: How to ensure a thread cannot be blocked by the GC?
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!
Re: How to ensure a thread cannot be blocked by the GC?
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… ;-)
Re: How to ensure a thread cannot be blocked by the GC?
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.
How to ensure a thread cannot be blocked by the GC?
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?
Re: How to ensure a thread cannot be blocked by the GC?
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.
Re: How to ensure a thread cannot be blocked by the GC?
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
Re: How to ensure a thread cannot be blocked by the GC?
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
Re: How to ensure a thread cannot be blocked by the GC?
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.
