I'm making a port of the AKKA framework for .NET
Sweet. I went to an Akka talk at CodeMash '13 despite having never touched Java/Scala/Akka. I saw a lot of potential there for a .NET library/framework. Microsoft is working on something similar, which I hope will eventually be made generally available (it's currently in a limited preview).
I suspect that staying in the Dataflow/Rx world as much as possible is the easier approach; async
is best when you have asynchronous operations (with a single start and single result for each operation), while Dataflow and Rx work better with streams and subscriptions (with a single start and multiple results). So my first gut reaction is to either link the buffer block to an ActionBlock
with a specific scheduler, or use ObserveOn
to move the Rx notifications to a specific scheduler, instead of trying to do it on the async
side. Of course I'm not really familiar with the Akka API design, so take that with a grain of salt.
Anyway, my async
intro describes the only two reliable options for scheduling await
continuations: SynchronizationContext.Current
and TaskScheduler.Current
. If your Akka port is more of a framework (where your code does the hosting, and end-user code is always executed by your code), then a SynchronizationContext
may make sense. If your port is more of a library (where end-user code does the hosting and calls your code as necessary), then a TaskScheduler
would make more sense.
There aren't many examples of a custom SynchronizationContext
, because that's pretty rare. I do have an AsyncContextThread
type in my AsyncEx library which defines both a SynchronizationContext
and a TaskScheduler
for that thread. There are several examples of custom TaskScheduler
s, such as the Parallel Extensions Extras which has an STA scheduler and a "current thread" scheduler.