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