Can anyone please explain me what it means for the D language to follow the Actor model, as the relevant Wikipedia page says it does? [1]

[1] http://en.wikipedia.org/wiki/Actor_model#Later_Actor_programming_languages

On Monday, 19 August 2013 at 03:11:00 UTC, Luís Marques wrote:
> Can anyone please explain me what it means for the D language to follow the Actor model, as the relevant Wikipedia page says it does? [1]
>
> [1] http://en.wikipedia.org/wiki/Actor_model#Later_Actor_programming_languages

I assume this refers to task in std.parallelism and the various bits in std.concurrency for message passing.

I'm very surprised that D made the cut but Go didn't. I'm even more surprised that Rust was included even though it's not even 1.0 yet while Go is at 1.1.1 currently.

I wish they had some kind of explanation or code examples to justify each one as in other articles, because I'm also very interested...

On 8/18/13 9:24 PM, Tyler Jameson Little wrote:
> On Monday, 19 August 2013 at 03:11:00 UTC, Luís Marques wrote:
>> Can anyone please explain me what it means for the D language to
>> follow the Actor model, as the relevant Wikipedia page says it does? [1]
>>
>> [1]
>> http://en.wikipedia.org/wiki/Actor_model#Later_Actor_programming_languages
>>
>
> I assume this refers to task in std.parallelism and the various bits in
> std.concurrency for message passing.
>
> I'm very surprised that D made the cut but Go didn't. I'm even more
> surprised that Rust was included even though it's not even 1.0 yet while
> Go is at 1.1.1 currently.
>
> I wish they had some kind of explanation or code examples to justify
> each one as in other articles, because I'm also very interested...

Go is CSP - isn't that different from Actor?

Andrei

On Monday, 19 August 2013 at 16:20:37 UTC, Andrei Alexandrescu wrote:
> Go is CSP - isn't that different from Actor?
>
> Andrei


I'd be interested to know the difference.

On Mon, 2013-08-19 at 09:20 -0700, Andrei Alexandrescu wrote: […]

> Go is CSP - isn't that different from Actor?

CSP certainly is very different from actors, it's in the synchronization structure. Go's model isn't CSP per se, it is a more or less the same thing developed by Pike over the years. At it's coarsest:

An actor processes a message from it's message drop as and when it wishes and send messages to other actors it know the message drop for asynchronously.

Processes in CSP rendezvous in order to pass messages down a one-to-one channel, which has no buffering. Modern CSP allows one-to-one, one-to-many, many-to-one and many-to-many channels with or without buffering. CSP processes with many-to-one channels with large buffering can appear very like actors.

Actors that are effectively event loops can be made to look an awful lot like CSP.

The are different but there are shades of grey (no not that sort of activity :-) so it is easy to see how people might get confused.

The third player here is dataflow, and this is increasingly used for "Big Data" and might be worth thinking about in std.parallelism.  An operator (a process as in CSP, but the whole model comes from 1970s dataflow computer research hence operator) is event driven. An operator springs into action when a pattern of data-readiness on it's inputs occurs. It them computes and outputs results on it's output channels.

We like dataflow.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 19 August 2013 at 03:11:00 UTC, Luís Marques wrote:
> Can anyone please explain me what it means for the D language to follow the Actor model, as the relevant Wikipedia page says it does? [1]
>
> [1] http://en.wikipedia.org/wiki/Actor_model#Later_Actor_programming_languages

To my understanding "Message Passing Concurrency" in D is already
very actor-like:

void main()
{
     Tid worker = spawn(&workerFunc, thisTid);
     worker.send(1);
}

void workerFunc(Tid owner)
{
     int value = 0;
     value = receiveOnly!int();
	writeln("value from parent: ", value);
}

Sample code above taken from the book by Ali Çehreli and then
simplified. This is such a breeze compared to spawning a thread
in C++ or Java. Question is what happens when you spawn some
thousand actors. I don't know whether the threads in D are made
for this.

-- Bienlein

On 11/05/2013 04:28 AM, Bienlein wrote:

>       Tid worker = spawn(&workerFunc, thisTid);

Going totally off topic here, there is ownerTid in every worker's context. (I suspect it was a relatively recent addition.) So, there is no need to pass the owner's tid explicitly:

     Tid worker = spawn(&workerFunc);

Then the worker uses the available ownerTid:

     ownerTid.send(2);

I will simplify those examples.

Ali

On Nov 5, 2013, at 4:28 AM, "Bienlein" <jeti789@web.de> wrote:
> 
>> On Monday, 19 August 2013 at 03:11:00 UTC, Luís Marques wrote:
>> Can anyone please explain me what it means for the D language to follow the Actor model, as the relevant Wikipedia page says it does? [1]
>> 
>> [1] http://en.wikipedia.org/wiki/Actor_model#Later_Actor_programming_languages
> 
> To my understanding "Message Passing Concurrency" in D is already very actor-like:
> 
> void main()
> {
>     Tid worker = spawn(&workerFunc, thisTid);
>     worker.send(1);
> }
> 
> void workerFunc(Tid owner)
> {
>     int value = 0;
>     value = receiveOnly!int();
>    writeln("value from parent: ", value);
> }
> 
> Sample code above taken from the book by Ali Çehreli and then simplified. This is such a breeze compared to spawning a thread in C++ or Java. Question is what happens when you spawn some thousand actors. I don't know whether the threads in D are made for this.

Threads in std.concurrency are currently all kernel threads. However, just yesterday I started working on a way to make that configurable by way of a user-defined Multiplexer class. The inspiration was to make it so message passing works with vibe.d so different logical threads could communicate. It seems like a pretty simple change so far, though I guess we'll see today. As a demo, I'm creating both a ThreadMultiplexer and a FiberMultiplexer.

On 11/05/2013 07:20 AM, Ali Çehreli wrote:

> On 11/05/2013 04:28 AM, Bienlein wrote:
>
>  >       Tid worker = spawn(&workerFunc, thisTid);
>
> Going totally off topic here, there is ownerTid in every worker's
> context. (I suspect it was a relatively recent addition.) So, there is
> no need to pass the owner's tid explicitly:
>
>       Tid worker = spawn(&workerFunc);
>
> Then the worker uses the available ownerTid:
>
>       ownerTid.send(2);
>
> I will simplify those examples.

Done:

  http://ddili.org/ders/d.en/concurrency.html

Ali

>It seems like a pretty simple change so far, though I guess we'll see today. As >a demo, I'm creating both a ThreadMultiplexer and a FiberMultiplexer.

That would be awesome. Something similar to lightweight threads
as in Go or Rust and I'm all happy with D ;-).