Recording of today's #rustlang stream on making the concurrency primitive behind evmap's fast concurrent reads generic is now up! I think it turned out pretty great, and am excited to see what people might do with it! https://www.youtube.com/watch?v=eLNAMEoKAAc
The PR (which still needs some cleanup before it'll land) is here for anyone who just wants to see where we ended up: https://github.com/jonhoo/rust-evmap/pull/73
I worked with my college to include evmap to store results of HTTP calls in a backhround process, so that the service PREvant can respond to its clients without doing the calls in the same request. Works pretty well and thanks for that cool crate.
Unfortunately, we had to wrap the used sructs in a Mutex to make it work with #Rocket: State<Arc<Mutex<HostMetaCache>>>
Thanks! Always cool to hear about my things being used. If you had to stick it in a Mutex anyway though, why use evmap?
@schrieveslaach Hmm, yeah, evmap is very opinionated in that the `ReadHandle` types can't be used concurrently from multiple threads at the same time. You need each future/task/thread to have its own `ReadHandle`. I feel like there should be a way to get that with Rocket, but don't know. With HTTP/2 you'd probably want something like a `ReadHandle` per request. Or you could try to go the route of thread-locals to hack around it, but pain lies that way. Maybe dashmap/flurry is a better fit?
@jonhoo I looked at the issues and PRs of Rocket. I think the issue might be resolved in the next version of Rocket. Cloneable states should be usable without Mutex: https://github.com/SergioBenitez/Rocket/commit/b7565172eb07e64e35e3cbb3d762281e001dc77e
Do you think that this is applicable to the ReadHandle or do you see any issue here? If this works with Rocket, evmap is a very good fit for building webapps.
@schrieveslaach Hmm, I'm not sure if `State: Clone` will be sufficient, since you'll still then need exclusive access to the `State` in order to use `ReadHandle`. And it particularly won't help if it still requires that the inner type is `Sync` (which `ReadHandle` is not)... I think this may just not fit Rocket's idea of `State`, which seems to be "something shared among all requests".
@schrieveslaach Hmm, I think that probably still won't do what you want. If I'm reading this right, it creates a new `ReadHandle` for every request, which is basically the same as taking a `Mutex` for each request (that's what `ReadHandleFactory::handle` does internally).
@jonhoo yes, you are reading it correctly. I did not notice that ReadHandleFactory uses an AtomicPtr internally. ReadHandle.clone() works the same, correct?
However, do you think this approach performs better because AtomicPtr works better than Mutex? I read that atomic structs perform better but I did not find any information on AtomicPtr specifically.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.