On Saturday, 18 November 2017 at 00:23:31 UTC, Ali Çehreli wrote:
We had an issue today calling a D shared library from our Java
code where we were getting segfaults during GC collection
cycles.
Of course we were being careful and calling
Runtime.initialize() inside our initialization function, which
is called from the Java side:
extern (C) auto mylib_init() {
const rtInit = Runtime.initialize();
if (!rtInit) {
logf("Failed to initialize D runtime");
abort();
}
// ...
}
but we were forgetting about the fact that our API functions
might be called from threads other than the one that called
Runtime.initialize().
extern (C) auto mylib_do_good_work() {
// Oops! A GC collection cycle may cause segmentation fault
here
// ...
}
A simple solution is to call thread_attachThis() from each API
function:
extern (C) auto mylib_do_good_work() {
import core.thread : thread_attachThis;
thread_attachThis();
// Now this thread is attached to D runtime and all is good
// ...
}
Although thread_attachThis() can be called multiple times from
the same thread, it may be possible to call it only once per
thread if potential calling threads are known; such threads can
call a per-thread initialization function on the D side. (We
don't think our Java program gives us that option because "our
Java code" is a callback registered with the framework of a
Java program, which has total control of its threads.)
Ali
I highly advise to attach incoming threads _and detach them when
they exit the callback_. Indeed when they have exited the
callback no need to scan their stack.
If you don't do this and the thread dies outside your library,
then your runtime still register it and will try to pause it at
the first collection.