The new actor framework is mostly complete, still a couple things left to do like coalescing and future chaining. But at this point it is time to start thinking about migration. My goal is that the actor API will completely replace the thread API, and that sys::Thread will go away.
I plan to do a build sometime this week with both APIs in place side-by-side which will give everyone a chance to migrate from threads to actors. After that I will remove the thread API completely.
For the most part of all of thread's functionality has been moved into Service, ActorGroup, and Actor. There are two methods that still need a home: sleep and locals.
I think locals gets moved to Actor and becomes the public state of the actor's Context. That allows thread locals to move around with the actor as it is scheduled on arbitrary threads by the actor's group.
Then I think sleep either moves to Sys or to Actor. Probably I will just move it to Actor.
JohnDGSun 29 Mar 2009
Then I think sleep either moves to Sys or to Actor. Probably I will just move it to Actor.
Do we need sleep? It seems to make more sense in message passing-based concurrency to get some timer or scheduler to fire a message off after the specified elapsed time.
brianSun 29 Mar 2009
Do we need sleep?
It certainly isn't a good technique to use in a serious actor application. But there are lots of cases for quick and dirty stuff where you just want to have a simple serial process (even if it consumes a thread from the actor's group). So I consider it a requirement.
brian Sun 29 Mar 2009
The new actor framework is mostly complete, still a couple things left to do like coalescing and future chaining. But at this point it is time to start thinking about migration. My goal is that the actor API will completely replace the thread API, and that
sys::Threadwill go away.I plan to do a build sometime this week with both APIs in place side-by-side which will give everyone a chance to migrate from threads to actors. After that I will remove the thread API completely.
For the most part of all of thread's functionality has been moved into Service, ActorGroup, and Actor. There are two methods that still need a home:
sleepandlocals.I think
localsgets moved toActorand becomes the public state of the actor'sContext. That allows thread locals to move around with the actor as it is scheduled on arbitrary threads by the actor's group.Then I think
sleepeither moves toSysor toActor. Probably I will just move it toActor.JohnDG Sun 29 Mar 2009
Do we need
sleep? It seems to make more sense in message passing-based concurrency to get some timer or scheduler to fire a message off after the specified elapsed time.brian Sun 29 Mar 2009
It certainly isn't a good technique to use in a serious actor application. But there are lots of cases for quick and dirty stuff where you just want to have a simple serial process (even if it consumes a thread from the actor's group). So I consider it a requirement.