• Antoche (65/65) Nov 26 2013 I'm trying to use taskPool.asyncBuf from std.parallelism since
• safety0ff (1/1) Nov 26 2013 Could be related to #10351 or #5488 in bugzilla.

"Antoche" <N A.c> writes:

I'm trying to use taskPool.asyncBuf from std.parallelism since 
std.concurrency seems broken 
(http://forum.dlang.org/thread/wpxygsxveghehdptjfzj forum.dlang.org).

I have a class that creates a custom Range and loops over it 
through a taskPool.asyncBuf inside its constructor. The elements 
returned by the Range are new class instances holding arrays, and 
those arrays are filled and resized at construction times.

I'm seeing a deadlock happening due to allocation. Stacktrace for 
the main thread shows:

Thread 1 (Thread 0x7ffff7fbb000 (LWP 19956)):

/lib/x86_64-linux-gnu/libpthread.so.0

















Stacktrace for the Range call:

Thread 5 (Thread 0x7fffed2b1700 (LWP 19986)):

/lib/x86_64-linux-gnu/libpthread.so.0

/lib/x86_64-linux-gnu/libpthread.so.0

/lib/x86_64-linux-gnu/libpthread.so.0




[...]



std.parallelism.TaskPool.[...].asyncBuf() ()





std.parallelism.TaskPool.executeWorkLoop() ()

std.parallelism.TaskPool.startWorkLoop() ()



/lib/x86_64-linux-gnu/libpthread.so.0

/lib/x86_64-linux-gnu/libc.so.6


My impression is that the main thread, going through the 
constructor, goes through gc.gcx.GC.malloc(). The second thread, 
resizing an array, also calls gc.gcx.GC.malloc(), which seems to 
be trying to lock a mutex. I'm guessing that mutex was locked by 
the first one? Or am I mistaken?