Hello,
I’m hoping to tap into the wisdom of the FDB team here.
If FDB were written in Java or .Net using their Async/Await libraries and we wanted to have a deterministic simulation framework that could simulate the FDB cluster on a single thread, what would our options be?
E.g. Taking the Flow/FDB approach, one could write language extensions in C# (say) that provide the actor semantics for developers, but get compiled into callbacks. I don’t think it will be feasible to leverage the Async/Await capabilities of the language anymore - but will be glad to be told that I’m wrong.
I tried to do exactly this in .NET/C#, and the most complex issue is not the async/await state machine, it’s the fact that actors have addresses and are passing messages to each others, across the network, and can listen for multiple types of messages. Adding that on top of the C# language was extremely difficult! something as easy to do as listening on multiple events (or channels as in go) is almost impossible to write cleanly in C#. You’d need to combine System.Reactive streams with some magic glue to “await” the same tasks multiple times, and you’d need to come up with some new syntax that allow you to write in a way that is understandable and maintainable.
Now, I use FDB under the hood to do the messaging between “actors” (using a custom layer), and only deal with the asynchrony at the C# level. So in a way I defer this issue back to flow itself
Appreciate your reply @KrzysFR . I think what you’re describing is a different solution though. Here, I meant ‘actors’ in a very restrictive sense, the way it is meant in the FDB/Flow paper – just synctatic sugar to get rid of nested callbacks.
For kicks OR as a mental exercise OR as a useful pattern for testing:
To deterministically simulate a service written in C# (say) on a single thread, we’d need alternatives for a bunch of language constructs like
Those from the System.Threading.* family like Tasks, TaskScheduler
Current time, CPU/disk utilization,
Random seeds
Async/Await
Non-blocking IO
…
Of these, I am curious how the Async/Await pattern would be handled.
