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
