Debugging D shared libraries

[rom via Digitalmars-d-learn]

On Saturday, 19 September 2015 at 10:45:22 UTC, Russel Winder 
wrote:
> Calling D from Python. I have two functions in D, compiled to a 
> shared object on Linux using LDC (but I get same problem using 
> DMD).
>
> The sequential code:
>
>     extern(C)
>     double sequential(const int n, const double delta) {
>       Runtime.initialize();
>       const pi = 4.0 * delta * reduce!(
>             (double t, int i){ immutable x = (i - 0.5) * delta; 
> return t + 1.0 / (1.0 + x * x); })(
>             0.0, iota(1, n + 1));
>       Runtime.terminate();
>       return pi;
>     }
>
> works entirely fine. However the "parallel" code:
>
>     extern(C)
>     double parallel(const int n, const double delta) {
>       Runtime.initialize();
>       const pi = 4.0 * delta * taskPool.reduce!"a + b"(
>           map!((int i){ immutable x = (i - 0.5) * delta; return 
> 1.0 / (1.0 + x * x); })(iota(1, n + 1)));
>       Runtime.terminate();
>       return pi;
>     }
>
> causes an immediate segfault (with LDC and DMD.  I am assuming 
> that the problem is the lack of initialization of the 
> std.parallelism module and hence the use of taskPool is causing 
> a problem. I am betting I am missing something very simple 
> about module initialization, and that this is not actually a 
> bug.
>
> Anyone any proposals?


Isn't it simply that when doing some work asynchronously, as with 
task pool, work is being done in other threads than the main. All 
the while, you're killing the Runtime. The fact that when 
removing  Runtime.terminate makes the code work might support 
that explanation.