These are chat archives for akkadotnet/akka.net

7th
Feb 2015
Aaron Stannard
@Aaronontheweb
Feb 07 2015 00:29
looks for deadlocks and other stuff that can happen in concurrent tests
Roger Johansson
@rogeralsing
Feb 07 2015 16:41
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
Aaron Stannard
@Aaronontheweb
Feb 07 2015 20:38
@rogeralsing very cool! a few questions about it:
  1. Any reason this shouldn't be the default dispatcher? (i.e. overhead, etc...)
  1. Will this work with configurable dispatchers (i.e. ones with fixed size threadpools) ?
damn, markdown list ordering doesn't work across posts :p
  1. 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?
Roger Johansson
@rogeralsing
Feb 07 2015 21:10
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
Aaron Stannard
@Aaronontheweb
Feb 07 2015 21:15
got it
ok, so not a good default then?
Roger Johansson
@rogeralsing
Feb 07 2015 21:17
Probably not, not sure whats worth the most, ease of use or speed? Then make the least worth opt in
Aaron Stannard
@Aaronontheweb
Feb 07 2015 21:17
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
Roger Johansson
@rogeralsing
Feb 07 2015 21:19
Exactly. Ill clean it up and publish in my repo and we can experiment with it
Aaron Stannard
@Aaronontheweb
Feb 07 2015 21:19
do you want to make it a contrib module or integrated into core?
contrib/dispatchers
Roger Johansson
@rogeralsing
Feb 07 2015 21:25
It could just aswell be integrated? Its just a dispatcher. Doesnt affect the rest of the system
Aaron Stannard
@Aaronontheweb
Feb 07 2015 21:25
I think that's fine
might as well, right?
Roger Johansson
@rogeralsing
Feb 07 2015 21:27
Yes, lets make it experimental and see what the community say
Aaron Stannard
@Aaronontheweb
Feb 07 2015 21:27
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
Roger Johansson
@rogeralsing
Feb 07 2015 21:32
Yepp
The good news, they only have this option, so they can never go fast
Aaron Stannard
@Aaronontheweb
Feb 07 2015 21:43
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