-
-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optional feature flag to use a DashMap as opposed to a HashMap #92
Comments
Hi. Thank you for the offer. Moka's concurrent cache implementations Lines 19 to 20 in 536aff2
Are you saying that you want an optional Cargo feature to use If so, could you please tell me the reasons you want the feature?
|
I was going to implement this into https://github.com/serenity-rs/serenity which uses a DashMap for caching and we were interested in implementing a TTL, so we found this crate. However, due to #34 it sadly looks like we aren't going to be able to use this crate. |
Thanks. I understood the reason. Let me add the feature. There will be some limitations. When the feature is enabled, cache will not support the following methods because I think you will be okay with the limitation above because you are currently using Also I think you are using but our caches do not provide iterators. Is this okay? |
Yes, this is all fine! Thank you very much for the swift response. However, the still major roadblock for us using this library is #34. If that can be resolved (no rush) then serenity will happily move over to using Moka. |
Ah, we do need |
The issue #34 (segfault) will not occur when this feature is enabled because:
Once I finish implementing this feature, I will run the same load tests that have triggered the segfaults. |
Okay. I created #93 "Iterating all entries in a cache". I hope it will not difficult to implement if |
Hey, We have discussed some design changes, and we are only going to use Moka as a temporary cache for things that don't update from events. Provided that the segfaults only happen on those functions, DashMap support isn't needed for serenity. |
@tatsuya6502 Regarding your previous post: DashMap does actually provide an equivalent for As for the overall issue being discussed- a feature flag is not likely the correct way to do this. Feature flags can arise from those set in your dependencies, and would alter the perceived function for your library. Unless the feature-flag enables a strict superset of functionality with no degradation or drawbacks, crate flags should not alter the behaviour of existing, compiling code. I'd suggest a generic parameter with a default to HashMap instead, and an alias that directly refers to the DashMap implementation's type. Additionally, by doing it this way, you gain the ability to plug-in other storage mechanisms as long as they fulfill a trait description used by the library. An example of a library that does this correctly is opentelemetry which has flags that enable compilation of various runtime adapters, but requires the caller to explicitly specify which to initialize when starting up the telemetry system. |
Ah, I see. That function is the only one with the vulnerability though? |
I have no idea what you mean by vulnerability. It was mentioned that a functionality was missing- but this was not the case; DashMap is indeed capable of upsert semantics. |
Not vulnerability, sorry. I meant does the issue mentioned in #34 only happen on those functions. |
That issue shouldn't happen at all, and I suggested that MIRI and Loom may be capable of isolating the root cause, but the segfaults appear to be specific to the HashMap being used by Moka, not the presence nor usage of an upsert function. |
Ah, thanks for the information. |
Hey 👋 any updates on this? No rush, just curious. |
Hi @Milo123459. Sorry, I am not making progress on this yet. I had been busy on some urgent stuff for three weeks and had no time to work on Moka. (These urgent stuff were mainly for my job, but some others for Japanese Rust community) Now those urgent stuff are basically done and I am going to resume my works on Moka. Let me finish up another work in Moka (#91), which I was working on a month ago, and then I will work on this. |
Thanks for the update! |
Hi @Milo123459 — I started to work on this. I added an optional To try it, add the following to the [dependencies]
moka = { git = "https://github.com/moka-rs/moka", branch = "master", features = ["dash"] } Then generate the Rust doc using the following command:
Open Please let me know if you are happy with it or you need me to add/change something. I wonder if you still need the iterator #93. I will start to run some load tests to ensure no segfaults occurs. Thanks! |
Thank you so much! Yeah, we still do need the iteration system. Thanks for also running some load tests! |
I ran the load tests and no segfault occurred. Merging pull request #99. |
Hey, I'm getting this issue: https://paste.rs/AHX It's a bit weird. I think this is related to moka and not serenity. |
Hi @Milo123459 — Can you please run |
Will do. It's updated loads of things, so I have some other issues to fix. |
Ah, it worked. |
Hi, sorry again. Is there a chance that |
Yes, it could implement |
Thank you so much! |
Hi @Milo123459 — I added |
Thank you once more! |
Will this be included in a release in the near future? |
Hi @Dessix — Yes. This will be included in next release v0.8.0 as an experimental feature. I am trying to release it by this weekend. |
Hi @Milo123459 and @Dessix — I have published Moka v0.8.0 with |
I'd be happy to implement this.
The text was updated successfully, but these errors were encountered: