#977 New concurrent pod (move Actor)

brian Sat 13 Feb 2010

I added a new concurrent pod with support for atomics which was something I really needed our commercial work.

The big question is does Actor and company (ActorPool and Future) belong in sys or concurrent?

I think it actually might make sense to move Actor out of the core and into concurrent. For things like JarDist, moving it out would shave lots of KB's from the required core library.

However there are a couple issues:

  • I believe sleep has to be available from the core, but we can move to Env
  • Actor.locals might be tricky not having in the core, but I think it can move
  • Any eventual async IO might be tricky if we don't have things like Future in sys

What do people say? Move Actor APIs to concurrent or leave them in sys?

jodastephen Sun 14 Feb 2010

The concurrent pod sounds like a logical place for actors.

tcolar Tue 16 Feb 2010

I like that.

And I like Sleep being in the core somewhere since it's so commonly use.

I remember wondering where it was the first time I needed it.

brian Thu 4 Mar 2010

Promoted to ticket #977 and assigned to brian

Move Actor, Future, and ActorPool APIs to concurrent

brian Thu 4 Mar 2010

Renamed from New concurrent pod to New concurrent pod (move Actor)

brian Wed 24 Mar 2010

Ticket cancelled

After a little more thought, I am not sure it is worth all the work to move Actor API. Given that we don't know how actors will fit into JavaScript web workers or async IO I'm sort of feeling the safest path is to just leave it in sys.

tactics Wed 24 Mar 2010

Sad. I was hoping to see this one. Leaving them in sys advocates Actors as the One True Way of concurrency, and as we all know, no such thing exists.

andy Wed 24 Mar 2010

we don't know how actors will fit into JavaScript web workers

This would actually be a vote for moving to concurrent I think - then we can replace wholesale the concurrent APIs available in JavaScript - since its highly unlikely they will look anything alike (at least in the near future).

Regardless - I do think Actor makes the most sense in concurrent - but I haven't dug into what would actually be involved in moving it - just need to make sure we assess this before we stamp 1.0.

brian Tue 11 May 2010

Ticket reopened

I am going to take another look at this tomorrow.

Right now I'm planning on doing a new build this week which has all the planned breaking changes behind us.

brian Wed 12 May 2010

Ticket resolved in 1.0.53

The Actor, ActorPool, and Future classes have been moved from sys to concurrent.

In general the only fix required to your code is to add a dependency and using statement for concurrent.

Login or Signup to reply.