I'd like to try it.
"In theory there is no difference between theory and practice, but in practice there is."
Discussion
Don't do it to my current machine. This was not permission to DDoS my domain! Hehe. I'd have to arrange it with the data centre first.
If you have only one thread per cpu, does that mean any requests from the sockets on that cpu are queued?
Sockets are not pinned to CPUs. Any thread (cpu) can pick up any task that is ready for further processing.
Are the requests process asynchronously from the database, for example, the requests are processed by one queue, but the database lookup is dispatched by the request processor, then the result is returned after the database has returned data. Such as; if you have two clients (A and B) making two separate requests, if A is processed before B (both in the same request handling thread), but the lookup for B returns data to be sent back before A, then B would get its respomse before A?
Yes it is all asynchronous. Within 'async rust', everything is asynchronous. There is no tricky coding on my part. Every function that says it returns a type T actually returns a future that resolve to a type T and the executor handles running that future to completion, even as that task sometimes returns Poll::Pending instead of Poll::Ready(data) in which case it gets shelved so the thread can keep itself busy with anything else that needs to be done. This is all internal to rust's async system and the executor which I use which is 'tokio' (there is another one async-std, but I don't think it ever got much uptake).
I take this back, see other response to the parent.
So rust's async is more like green thread than like microsoft's WDM deferred procedure calls?
yep
BTW it doesn't just repeatedly poll and keep getting Poll::Pending. When it gets one of those, it doesn't poll again until the waker system wakes up the task when the I/O is actually ready.
Shit, I seem to have entirely failed to async in the chorus-lib. Huge oversight.
Eh, nah it looks like `heed` (the LMDB library) isn't async so I couldn't do it if I wanted to. Data access is memory-mapped, and any delays happen in the kernel (I think) and are kind-of hidden to the application (kernel handles the page fault, our code is put to sleep while that happens), so hard to async in userspace in this case, but it should be fast nonetheless. Potentially a thread sleeps over a page fault when the CPU could have otherwise been busy, but probably not something we can fix.
All network waits are definately async futures.
The test could be run on an internal private network fairly easily. Each client could be on a separate VM, possibly even all 20 clients could be on one machine and it done with the bridge interfaces of docker containers.