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:
What do people say? Move Actor APIs to concurrent or leave them in sys?
The concurrent pod sounds like a logical place for actors.
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.
Promoted to ticket #977 and assigned to brian
Move Actor, Future, and ActorPool APIs to concurrent
Renamed from New concurrent pod to New concurrent pod (move Actor)
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.
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.
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.
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.