It seems that the receive function, immediately on processing a message, is terminating it's thread silently. So the question now is under what circumstances does std.concurrency.receive exit its thread without notice?


On Thu, 2018-05-31 at 17:29 +0100, Russel Winder wrote:
> I am fiddling again with writing a D version of Me TV to compare with
> the C++ (already declared dead), and the Rust version (currently the
> 'real' version).
> 
> From the main thread (which eventually becomes the GTK+3 event loop thread) I spawn three threads to create "actors" that pass messages. Actually it is a pipeline.
> 
> 1 → 2 → 3
> 
> The intention will then be that Actor 3 communicates with the GTK+3 event loop in whatever way is allowed.
> 
> All three threads seem to start. 3 always goes straight into receive.
> In some circumstances 2 sends messages to 3 before it enters it's
> receive, in other circumstances it goes straight into receive. 1
> alternates between a listening activity not to do with the threads
> and
> a receive (for termination). 1 and 2 are seen to execute sends to the
> correct Tid, but no receive ever executes. I tried putting Variant as
> the last option to see if there were message but just of the wrong
> type, and… no message received. It seems that receive is blocking and
> never being triggered even though provably there are sends that
> should
> trigger a receive.
> 
> So I assume I am doing something very silly that causes this, or my code is wrong in some other way.
> 
> The code is at:
> 
> https://github.com/russel/Me-TV_D
> 
> src/inotify_daemon.d contains Actor 1 code. src/frontend_manager.d contains Actor 2 code. src/control_window.d contains Actor 3 code.
> 
> src/main.d has the startup code.
> 
-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk