search

akkadotnet / akka.net

Canonical actor model implementation for .NET with local + distributed actors in C# and F#.
http://getakka.net
Other
4.72k stars 1.04k forks source link

Port AffinityPool #2846

Open Horusiath opened 7 years ago

Horusiath commented 7 years ago

See: https://github.com/akka/akka/pull/23104 and https://github.com/akka/akka/pull/23315

I must admit, this was something I was thinking about myself. We could create a task scheduler, which would pin an actor execution to the particular threads. What I hope for is beside avoiding moving between thread caches, we could potentially fix the problem of loosing actor's Context/Self references in taks continuations.

Danthar commented 7 years ago

So if i understand this correctly. It allows one to pin an actor, or a group of actors, to a specific AffinityPool, therefore forcing those actor(s) to always run on a certain thread. Right ?

Horusiath commented 7 years ago

Yes. There's an article which describes the problem in greater detail: https://blog.scalac.io/improving-akka-dispatcher.html

rogeralsing commented 7 years ago

Isn't this exactly what we did with the very early versions of the dedicated thread pool? Which we later scrapped as zombie actors hogging a thread would prevent any other actors scheduled onto the same thread queue to run.

So at least be weary of the risk here (unless I'm really missing something in the affinity pool)

Horusiath commented 7 years ago

@rogeralsing I think, we indeed could talk about it in early days, but I cannot recall what were our concerns there. By zombie actors hogging you mean actor doing a long-running thread blocking operations? I guess it's not the issue of dispatcher itself, rather a design issue. There's also a blog post from ScyllaDB, which also seems to choose similar direction.

rogeralsing commented 7 years ago

By zombie actors hogging you mean actor doing a long-running thread blocking operations?

Yes.

And absolutely, but a framework that is supposed to help with fault tolerance and compartmentalization, if that framework lets design issues in one actor cascade over to other actors due to the design of the dispatcher, then that is a bad design in itself.

just my 2 cents, but IMO favoring isolation over synthetic performance gains is better.

Horusiath commented 7 years ago

I think, we could offer a choice with both - safe, isolated dispatcher vs. constrained affinity pool - question is more, which should be the default. While there should be a way to work with long running thread blocking ops, my bet is that for 99% of the time it's not the case.

rogeralsing commented 7 years ago

First, try it out and see how it works. is there a significant gain? is it worth the risk etc. (Scheduling on .NET != scheduling on JVM. very different behaviors.)