Hi, I have a C library that uses multi-threading and implements a callback architecture by this. It runs on Windows and *nixes (pthreads). I would like to use it from D.

I understand that the ABI of D is C compatible, so I would expect that there shouldn't be any problems with threading as well. Can I somehow use D's threading features in combination with the libraries C features? Or is it better to completely keep the two seperate?

Has anyone any experience in mixing D and C in multi-threaded envrionments?

Thanks for the feedback.

-- 
Robert M. Münch
Saphirion AG

http://www.saphirion.com
smarter | better | faster

> I understand that the ABI of D is C compatible, so I would expect that there shouldn't be any problems with threading as well.

D uses pthread for core.Thread and core.sync.*

> Can I somehow
> use D's threading features in combination with the libraries C features?
> Or is it better to completely keep the two seperate?

I wouldn't mix core.Thread/std.parallelism/std.concurrency with C threading. Like calling a core.Thread.Thread from a threaded c callback, but it might even work.


> Has anyone any experience in mixing D and C in multi-threaded envrionments?

I used std.parallelism together with stb_image.c to load images concurrently into memory, worked very well!

On 2013-01-12 17:32:21 +0000, David said:

>> I understand that the ABI of D is C compatible, so I would expect that
>> there shouldn't be any problems with threading as well.
> 
> D uses pthread for core.Thread and core.sync.*

On all platforms?

> I wouldn't mix core.Thread/std.parallelism/std.concurrency with C
> threading.

Ok.

> Like calling a core.Thread.Thread from a threaded c callback,
> but it might even work.

Maybe I just need to give it a try.

> I used std.parallelism together with stb_image.c to load images
> concurrently into memory, worked very well!

Just to be sure that I understand this right. The C part is not multi-threaded in your case, right? So, you used D's threading in combination with some C code.

-- 
Robert M. Münch
Saphirion AG

http://www.saphirion.com
smarter | better | faster

On Saturday, 12 January 2013 at 16:41:38 UTC, Robert M. Münch wrote:
> Hi, I have a C library that uses multi-threading and implements a callback architecture by this. It runs on Windows and *nixes (pthreads). I would like to use it from D.
>
> I understand that the ABI of D is C compatible, so I would expect that there shouldn't be any problems with threading as well. Can I somehow use D's threading features in combination with the libraries C features? Or is it better to completely keep the two seperate?
>
> Has anyone any experience in mixing D and C in multi-threaded envrionments?
>
> Thanks for the feedback.

If you're using a thread created from a C library, and it uses the GC, you'll need to call thread_attachThis (http://dlang.org/phobos/core_thread.html#.thread_attachThis) on each thread that uses it so that the GC knows to suspend the thread during a collection. If you don't do this, you'll get random segfaults and other issues.

Am 12.01.2013 20:28, schrieb Robert M. Münch:
> On 2013-01-12 17:32:21 +0000, David said:
> 
>>> I understand that the ABI of D is C compatible, so I would expect that there shouldn't be any problems with threading as well.
>>
>> D uses pthread for core.Thread and core.sync.*
> 
> On all platforms?

IIRC only posix

>> I wouldn't mix core.Thread/std.parallelism/std.concurrency with C threading.
> 
> Ok.
> 
>> Like calling a core.Thread.Thread from a threaded c callback, but it might even work.
> 
> Maybe I just need to give it a try.
> 
>> I used std.parallelism together with stb_image.c to load images concurrently into memory, worked very well!
> 
> Just to be sure that I understand this right. The C part is not multi-threaded in your case, right? So, you used D's threading in combination with some C code.

Yes, but make sure the C-code is threadsafe, before stb_image I was using DevIL, kept segfaulting.

On 2013-01-13 00:35:51 +0000, Kapps said:

> If you're using a thread created from a C library, and it uses the GC, you'll need to call thread_attachThis (http://dlang.org/phobos/core_thread.html#.thread_attachThis) on each thread that uses it so that the GC knows to suspend the thread during a collection. If you don't do this, you'll get random segfaults and other issues.

Not sure I understand. I assume you mean by "create a thread from a C library" creating a D thread? My idea was that a C thread isn't using the GC, only D code does.

I have it the other way: D main program, which starts C threads. And yes the C code is thread safe.

-- 
Robert M. Münch
Saphirion AG

http://www.saphirion.com
smarter | better | faster

On 2013-01-13 10:57:37 +0000, David said:

>> On all platforms?
> 
> IIRC only posix

How is threading done on Windows?

-- 
Robert M. Münch
Saphirion AG

http://www.saphirion.com
smarter | better | faster

Am 13.01.2013 15:47, schrieb Robert M. Münch:
> On 2013-01-13 10:57:37 +0000, David said:
> 
>>> On all platforms?
>>
>> IIRC only posix
> 
> How is threading done on Windows?
> 

https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d

Oops ... seem to have accidentally sent an email reply before.  Let's try again....

On 13/01/2013 14:46, Robert M. Münch wrote:
<snip>
> I have it the other way: D main program, which starts C threads. And
> yes the C code is thread safe.

You mentioned callbacks in your original post.  Does this mean that the C code may call D functions from the threads it creates?  And do said D functions use the GC either directly or indirectly?  If so, you will need to use attachThis at the beginning of each callback, and then detachThis when you're done.  (But you might be able to get away with less than this, depending on how the library uses threads and invokes callbacks from them.)

I haven't tried it, as I haven't had reason to use a C multi-threaded library in D code.  But going by the documentation, what attachThis does is to create a D thread object for the thread created by the C library, so that
(a) the GC will pause the thread in order to perform GC
(b) any pointers to GC memory held by the thread will be followed

OTOH, detachThis releases the thread from the GC, thereby making it safe for the C library to destroy the thread after it's finished with it.

Stewart.