Processes and Channels, cf. goroutines.

[Bienlein]

On Wednesday, 5 February 2014 at 20:37:44 UTC, Sean Kelly wrote:

> As for when this will be available... I will have a pull request
> sorted out shortly, so you could start playing with it soon.  It
> being included in an actual release means a review and such, but
> as this is really just a fairly succinct change to an existing
> module, I hope it won't be terribly contentious.

Sounds good. So, I only need to watch the Github repo for phobos 
and I will get notified? Or do I need to watch some other repo 
for D on Github? Just to be in the save side since I'm new to D 
and not familiar with the way things are split up.

> ... And second, I wasn't terribly fond of
> the "sequential" part of CSP.  I really want a messaging model
> that scales horizontally across processes and across hosts, and
> the CSP algebra doesn't work that way.

What is nice about CSP is that you can proof that your code is 
free of deadlocks. The Go guys have developed a tool that parses 
the code and then tells you what it has found.

> As some general background on actors vs. CSP in std.concurrency,
> I chose actors for two reasons.  First, the communication model
> for actors is unstructured, so it's adaptable to a lot of
> different application designs.

Yeah, I understand the reasoning. CSP is somewhat from its level 
of granularity between low-level locks/semaphores/etc. and 
high-level actors. I guess you can easily build actors on top of 
CSP. In case of D actors are not that blown up as for example in 
Scala or Akka. Creating an actor is mostly like spawning a 
thread. So actors in D are much less heavy than in Scala/Akka. 
Actors in D must also have a message queue like channels in CSP 
where the message is inserted when some tid.send(...) is done. It 
is only not accessible from the outside.

> ...  It's possible this can be extended somehow, but I
> didn't investigate.  And since I don't currently have a great 
> way
> to block fibers, what I was doing there was a busy wait, which
> was just slow going waiting for all the threads to spin up.

Goroutines in Go are also co-operative, but I'm not sure (e.g. 
not pre-emptive). They probably yield when a channel has run 
empty. Well, then they have to in order to detach the thread that 
serves the channel to prevent the system to run out of threads. I 
guess they may have a strategy when to yield based on how long 
other channels had to wait to get a thread attached to them. For 
that purposes maybe there is a way to measure the traffic in the 
message queues of actors in D to get some effective yielding 
done. Just some thought. I'm not really an expert here.

> Heh, here is more interesting interpretation of this article 
> http://versusit.org/go-vs-ruby

Thanks for the link. Seems like the whole success story in this 
article in using Go is based on using goroutines and channels. So 
getting something similar accomplished in D would be important 
for D to be used for scalabale/elastic server-side software. Rust 
is basically using the same approach as Go with regard to 
threading. There seems to be something to it.

Cheers, Bienlein