Send never returns

Bob Cowdery bob at bobcowdery.plus.com
Thu Sep 30 14:21:24 PDT 2010


 On 30/09/2010 20:58, Jonathan M Davis wrote:
> On Thursday 30 September 2010 12:13:02 Bob Cowdery wrote:
>>  Hi
>>
>> I'm just starting to debug some code and have run into a problem.  There
>> is a bit too much code to post so as a first shot I wondered if anyone
>> has had this happen.
>>
>> I have a thread in a read loop reading from a USB device. When it
>> accumulates enough data it dispatches it to another thread. The read
>> loop is working fine and I can see the accumulated data but when I call
>> tid.send() it never returns. There are no errors. I have not put in
>> exception handling yet and wondered about the default behavior when
>> exceptions are not caught. Are they just passed up and spat out on the
>> console? I know it's a long shot but does anyone have any ideas.
>>
>> bob
> There are various bugs with std.concurrency at the moment that make it so that 
> it doesn't always work. For instance, I reported this bug on std.concurrency: 
> http://d.puremagic.com/issues/show_bug.cgi?id=4601 It relates to threads not 
> terminating and/or other threads not running after another thread has run. There  
> are, I believe, other similar bugs which have been reported, though I'd have to 
> go searching to see what they are.
>
> Personally, I find std.concurrency totally unusable at the moment. It rarely 
> works for me, and I just don't trust it. I really _want_ to use it, but it's 
> just too buggy right now.
>
> - Jonathan M Davis

Is this a bug?

I've tracked down this particular issue. It seems that if a thread (B)
is spawned from another thread (A) then A can message B but if B tries
to message A it never returns. However, B and C can communicate Ok. I
did have three threads, A spawning B &C. I now have just B &C with a
receive loop in the main thread which appears to work. Everyone can
message everyone else.
 
I can't do this app without threads and I really want to use message
passing concurrency. If it's really unreliable that's going to be a stopper.

bob




More information about the Digitalmars-d-learn mailing list