www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Actor model & D

reply =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
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
Aug 18 2013
next sibling parent reply "Tyler Jameson Little" <beatgammit gmail.com> writes:
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...
Aug 18 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 19 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Aug 19 2013
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2013-08-19 at 09:20 -0700, Andrei Alexandrescu wrote:
[=E2=80=A6]

 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. =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Aug 19 2013
prev sibling next sibling parent reply "Bienlein" <jeti789 web.de> writes:
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
Nov 05 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Nov 05 2013
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Nov 07 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Nov 5, 2013, at 4:28 AM, "Bienlein" <jeti789 web.de> wrote:
=20
 On Monday, 19 August 2013 at 03:11:00 UTC, Lu=C3=ADs Marques wrote:
 Can anyone please explain me what it means for the D language to follow t=


=20
 [1] http://en.wikipedia.org/wiki/Actor_model#Later_Actor_programming_lang=


=20
 To my understanding "Message Passing Concurrency" in D is already
 very actor-like:
=20
 void main()
 {
     Tid worker =3D spawn(&workerFunc, thisTid);
     worker.send(1);
 }
=20
 void workerFunc(Tid owner)
 {
     int value =3D 0;
     value =3D receiveOnly!int();
    writeln("value from parent: ", value);
 }
=20
 Sample code above taken from the book by Ali =C3=87ehreli 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 y= esterday I started working on a way to make that configurable by way of a us= er-defined Multiplexer class. The inspiration was to make it so message pass= ing works with vibe.d so different logical threads could communicate. It see= ms like a pretty simple change so far, though I guess we'll see today. As a d= emo, I'm creating both a ThreadMultiplexer and a FiberMultiplexer.=20=
Nov 05 2013
prev sibling parent "Bienlein" <jeti789 web.de> writes:
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 ;-).
Nov 08 2013