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
