Druntime and non-D threads

[Ali Çehreli]

On 12/08/2017 02:54 AM, Nemanja Boric wrote:
> On Friday, 8 December 2017 at 09:33:03 UTC, Ali Çehreli wrote:
>> 5) We depend on SIGUSR1 (and SIGUSR2, which may not be necessary but 
>> it's a different topic) to suspend non-D threads. Does that work with 
>> all threads? What if the calling framework has other uses for those 
>> signals? Would we be interfering with them?
>>
> 
> As the signal handlers are setup per-process, having the non-D threads 
> setup `SIGUSR1/2` will probably screw the entire GC, not just for these 
> threads. I feel you must ensure that the non-D threads don't try to 
> setup these handlers after the `rt_init` (which in turns calls 
> `thread_init`) is called, otherwise you're screwed. This is also valid 
> in inverse - you shouldn't use SIGUSR1/2 in non-D threads, since after 
> calling `rt_init` the signal handlers will be replaced with druntime's 
> ones.

So, in cases where D is just a portable library, the only sane thing to 
do seems to be what Kagamin suggested: create a D thread and send 
requests to it.

That way, we would be in total control of our threads, making 
entry-attach/exit-detach calls unnecessary. Agreed?

Ali