On 05/09/2014 02:51 PM, Joshua Niehus via Digitalmars-d-learn wrote:
Hi Charles,
would the following work (just a shot in the dark) ?
//---
module test;
import std.stdio;
import std.concurrency;
void spawnedFuncFoo(Tid tid, Tid tidBar) {
receive(
(int i) {
writeln("Foo Received the number ", i);
send(tidBar, i, thisTid);
auto barSuccessful = receiveOnly!(string);
writeln("Bar got my (Foo) message");
}
);
send(tid, true);
}
void spawnedFuncBar(Tid tid) {
receive(
(int i, Tid tidFoo) {
writeln("Foo passed me (Bar) the number ", i);
send(tidFoo, "done");
}
);
receive(
(string sig) {
writeln("Main says I'm (Bar) done.");
send(tid, 42);
}
);
}
void main() {
auto tidBar = spawn(&spawnedFuncBar, thisTid);
auto tidFoo = spawn(&spawnedFuncFoo, thisTid, tidBar);
send(tidFoo, 42);
auto fooWasSuccessful = receiveOnly!(bool);
assert(fooWasSuccessful);
send(tidBar, "your done");
auto barWasSuccessful = receiveOnly!(int);
assert(barWasSuccessful == 42);
writeln("Successfully had two separate threads communicate
with each other");
}
//---
Thank you very much for the response.
How do you ensure that the received message (in "auto barWasSuccessful =
receiveOnly!(int); ") came from the thread sent to by tidFoo? Also, why
two receives in
spawnedFuncBar? I thought that receive handled multiple different
arguments with a single receive? Are you asserting that the arguments
happen in sequence, as it appears? That doesn't look as if it would
scale will to multiple threads. And with multiple threads I would
expect the mailbox to start getting very full with inappropriate
messages that never got handled, because they came at the wrong time
(and arguably from the wrong sender, as it seems that there is an
assumption that there is no intervening thread sending any messages).
That's why I was looking for a way to ensure that the message being
received came from the appropriate sender. You can't depend on messages
to always come from the source you expect. This probably means that you
need to have only ONE receive statement, located in a loop. And some
way to check and set the status of incoming messages. Also a yield
method that lets one receive and stack any incoming messages during a
busy cycle, though I think that that's what receive does.
OTOH, I do note that you are using "auto barWasSuccessful =
receiveOnly!(int);" which implies that the value returned is not a void,
even though you never use the result. This fits with the claims of
TDPL, but make me increasingly dubious about the documentation. Or do I
just not understand what a function of type void is supposed to return?
The hashtable itself will be a uint64_t[string] which is confined to one
thread, so the access methods need to be rather straightforwards. I'm
thinking of:
receive
( (string s, uint64_t id) { void set(s, id); }
(string s) { void get(s); }
(Variant v) { void reportError (v); }
);
get should send the id back to the calling thread. set updates the AA
and sends true or false (success) back to the calling thread. But
doesn't this design lock the entire hashtable while the update is in
progress? Is there a better way? set will be, approx:
void set (string s, uint64_t id)
{ tbl[s] = id;
send (tid, true);
}
etc. But I'm worried about the receiving end. It needs, somehow, to
ensure that the message it receives is the appropriate message, and that
other messages don't get dropped while it's waiting for the answer...or,
perhaps worse, substituted for the expected answer. If I can depend on
msg[0] of "auto msg = receiveOnly!(Tid, bool)" that will allow me to
check that the message was received from the proper source Also, if a
message is received that if of an inappropriate form, an exception is
thrown. Recovery looks problematic. But this is a case that should be
expected when different threads are sending messages. And if the
message is of the correct form, but from the wrong thread, how can one
re-queue it for later processing?
So far the best idea I've got is to have a dequeue of messages that are
stacked with "receiveOnly!Variant". But this would need to be accesses
in various places throughout the thread, and the handling looks messy.
OTOH, it does let me save messages that come in at the wrong time where
I can deal with them later. So it's not all bad. But it gives up on the
processing that receive makes available. And note that this processing
doesn't need to be done in the hashtable function, that's pretty clear,
but wherever it's used. Which is terrible. As it is, I might be better
putting the hashtable in s synchronized class. The entire hashtable is
getting locked on every read anyway.
-- Charles Hixson
