[dmd-concurrency] socket to me

[Sean Kelly]

On Jan 19, 2010, at 11:10 PM, Kevin Bealer wrote:

> (Um, ignore the empty message I just sent.)
> 
> Earlier in this mailing list, it was mentioned that socket based connections and inter-thread communication might both benefit from the message passing design.  If I might jump the gun a bit (*), how do folks envision the socket based system working?  If I bring up a new process, can it read a config file for a host and port, then use that to join an existing set of processes that somehow do D-messages-over-sockets?

Haven't decided how to configure the listen port, but at an API level I think it will be roughly like Erlang in that a Node can be used to represent a process/host, etc.  When sending a message, there will be a routine that is ignorant of whether the recipient is local or remote.

> Do we envision application (user) defined gateway processes on each end of the socket or would the various CIDs in both processes be able to address each other directly?  In other words, would we have a message passing fabric with the inter-process relationships being destinations, or is the socket a conduit for the message passing system's 'address' space so that addressing on either side of the conduit is potentially transparent like handing a letter to a postman (e.g. you don't need to tell him how to get it there)?

Every process will be listening on only one port, if that answers your question.  The only real difference between local and remote messaging is that with remote messaging you can only send a message to a named recipient.  For example:

auto tid1 = spawn(&fn); // anonymous, accessible only via the returned tid
auto tid2 = spawn("happy", &fn); // named "happy" and visible in the process registry by this name

So sending a message to this node could be done by combining the Node instance representing the process and the name "happy".  There will likely also be something like EPMD (Erlang's port-mapper daemon), but that's a ways off and I'll have to re-think the details when we get to that point.

It may ultimately be possible to open dedicated channels on which to send messages, but it isn't something I'd considered yet.

> I don't think we should come up with a design for it now -- but some of these decisions impact the message passing API in semi-subtle ways, so if there were a few broad strokes it would make it easier to think about the ramifications of message passing and clustering on each other.

I've been following Erlang for the basic design, so that would be a good place to look for a rough idea of how things will work.  I'd offer more details, but my physical memory is full and that's been pushed out to disk somewhere.  I'm pretty confident that we can add socket-based messaging later on without changing anything discussed so far, however.