@smalldave looks like the
Coroner does something very JVM-specific in Akka: https://github.com/akka/akka/blob/cb05725c1ec8a09e9bfd57dd093911dd41c7b288/akka-testkit/src/test/scala/akka/testkit/Coroner.scala
looks for deadlocks and other stuff that can happen in concurrent tests
I have a working async await scheduler for akka.net now :) it preserves message and sender from before the await... it is what orleans call "reentrant" , that is, we can process messages while the await executes, so local state could be different before and after the await, but we can not get race conditions...
should we offer this as an drop in feature? it is only a different message dispatcher
@rogeralsing very cool! a few questions about it:
- Any reason this shouldn't be the default dispatcher? (i.e. overhead, etc...)
- Will this work with configurable dispatchers (i.e. ones with fixed size threadpools) ?
damn, markdown list ordering doesn't work across posts :p
- Has this been integration tested with ASP.NET / WPF to make sure that we don't do anything weird to their thread contexts and such?
It only works with that specific dispatcher, it could probably be extracted into some pre-step to all sispatchers.
It does however add massive overhead to message processing, probably not noticable on io bonund work, but for the ping Pong benchmark, it is magnitudes slower
So some opt in/opt out must be in place
got it
ok, so not a good default then?
Probably not, not sure whats worth the most, ease of use or speed? Then make the least worth opt in
I would make it an opt-in thing
if someone really super want
async and await
they can deploy actors with that dispatcher
otherwise, we should let them get the high performance option by default
Exactly. Ill clean it up and publish in my repo and we can experiment with it
do you want to make it a contrib module or integrated into core?
contrib/dispatchers
It could just aswell be integrated? Its just a dispatcher. Doesnt affect the rest of the system
I think that's fine
might as well, right?
Yes, lets make it experimental and see what the community say
I agree
I think that teaching people to treat
Task instances as messages sources (with PipeTo) is the "right way" to do async inside an actor
but I can't argue with giving developers the option to do it a different way if we can support it :smile:
especially if it gives feature parity with Orleans, because you know that'll come up every now and then :p
Yepp
The good news, they only have this option, so they can never go fast
yeah, I think it's good to have knobs and dials
but the out of the box option should be the common case / low overhead one
brb, think I need to restart my machine