[dmd-concurrency] Sending mesages to non-listening threads

[Sean Kelly]

On Jan 12, 2010, at 12:12 PM, Steve Schveighoffer wrote:

> ----- Original Message ----
> 
>> From: Michel Fortin <michel.fortin at michelf.com>
>> 
>> It's nice that you can now send messages to any thread like this:
>> 
>>    tid.send(i);
>> 
>> But... what if you're sending a message to the wrong thread, to a thread that 
>> isn't listening for messages? Do the messages accumulate in memory until no 
>> memory is left? If that's the case, sending messages to the wrong thread would 
>> become a memory leak. Any solution?
> 
> Maybe a thread who doesn't want messages can close his incoming message handle?  Similar to a disconnected socket, the sender will get an exception or something (and trying to receive a message in such a thread would get an exception).

I don't think someone will often send a message to the wrong thread.  The only default way to get a Tid is to be the one who spawned it (since spawn() returns a Tid) or to have looked it up in a registry by name.  I suspect they'll be passed around in messages as well, but it doesn't seem likely that an app will be lost in a sea of Tids.

I don't know that we want to try and guarantee any response for a failed send.  Remember, this same API has to have identical behavior for threads living somewhere across the network as locally.  It's feasible to provide a means of being notified when a thread dies (or becomes unreachable), but if the sender wants a return receipt for messages I think he should build that into his protocol.  Firewall issues may prevent this from always working anyway, and that's something only the user would be aware of.

As for closing the message handle, that should be trivial if people really want it.  Message queues are turned off but left for the GC to clean up when a thread dies anyway, so this would simply be a matter of exposing the "disable my queue" function to the user.  In a disabled queue, any messages received are simply dropped on the floor.

> The other possibility is to only allow so many messages to be queued before the queue is "full".  Unsure what you want to do at that point though, either block or return an EAGAIN type error (maybe you can do both depending on how you want to send the message).  This solution is at least more likely to show logic errors, since with the first solution you may forget to close the handle.  But it also could cause deadlocks or force you to write handling code for full queue conditions.
> 
> How does erlang handle this?

The way I described above.  What I'm shooting for with this API is to provide a basic set of operations on top of which more complex designs could be built if desired.  If you want CSP-like channels you can build that on top of send/receive, if you want a synchronous protocol you can do that as well, etc.  The last thing we want is for no one to use our messaging system because it makes assumptions that don't match some common use case we didn't think of.