Recording of today's 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!

The PR (which still needs some cleanup before it'll land) is here for anyone who just wants to see where we ended up:

@jonhoo as you are wondering what people might do with evmap, here is an example:

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. :ac_delight:

Unfortunately, we had to wrap the used sructs in a Mutex to make it work with : 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?

Unfortunately, we had to use the Mutex otherwise the code does not compile. 's State requires the type argument to be Send and Sync. Do you think there is a trick to avoid the usage of Mutex in conjunction with and ?

@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:

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".

@jonhoo I got a tip from the Rocket maintainers. The trick is to use ReadHandleFactory:

Sorry for bothering you.

@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.

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.