search

rsimmonsjr / axiom

Implementation of a highly-scalable and ergonomic actor model for Rust
Other
184 stars 21 forks source link

Implement AidPool's: A Simple Mechanism for Actor Pools #139

Open zicklag opened 4 years ago

zicklag commented 4 years ago

I'm not 100% sure that this is the right idea, but I was looking for a way to send messages to a pool of identical actors in a manner that was similar to a thread pool. I'd love to get feedback on whether or not this is a good approach to this.

My use-case was that I had an actor that would send HTTP notifications when it received messages, but if there were a lot of notifications that needed to be sent at the same time, I didn't want it to wait for that actor to finish sending a notification before it could send another one. Using an actor pool was my attempt at a solution. You can use spawn_pool to tell the system to spawn a number of identical actors and return an AidPool ( or rather something that implements the AidPool trait, currently only implemented by RandomAidPool ). AidPool has send(), send_new(), etc. functions and the RandomAidPool implementation will send messages to a random Aid in the pool. A better implementation might send a message to any non-busy actor, but I didn't know how or if there was any way to tell whether an actor was busy or not.

The PR comes with a test for spawn_pool and some documentation for the new types/functions.

Right now the test fails randomly from a send timeout, and I don't know why that is. I could maybe use some help understanding what causes that. I seems like it might be related to a similar random test failure ( caused by a timeout ) in that is occurring in the executor::tests::test_actor_awake_phases test on master right now.

This pulls in the rand and rand_xoshiro crates for the RandomAidPool implementation and I wasn't sure if we wanted that by default so I put it behind the actor-pool feature. If you would rather not have the feature, it would be easy just to take out the feature gates.

I'm not 100% sure that the choice of the Xoshiro random generator was the right one, but it is one of the fastest random generators according to the table in the Rust random book so that is why I went with it. It also has the nifty jump() feature that can be used to make sure that a clone of the random generator won't yield overlapping values for a large number of samples, which is useful when cloning the AidPool to make sure that the clones of the pool don't end up doubling up on sending messages to the same actors.

zicklag commented 4 years ago

Fixed the test and found out why it was timing out. It was because the channel size was too small.

I think this should be ready now, if this is even the right idea. :smiley:

zicklag commented 4 years ago

Updated some documentation, but CI is now failing because of executor::tests::test_actor_awake_phases again.

rsimmonsjr commented 4 years ago

I apologize for my absence. I am looking at this PR now.