-
Notifications
You must be signed in to change notification settings - Fork 238
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
Share support #585
Comments
The Share API is pretty unsafe, as you have to bring your own mutexes and manually keep track of references to avoid use-after-free. It might be doable, but would be tricky I think. It would have to be implemented in a way that:
Given those constraints I don't see any reason why we wouldn't accept this to be added to the API, as it could be useful in some scenarios. For design, I messed with this API several years ago, though I never finished it. Probably the most realistic approach would be to use an Arc internally in our Share wrapper. The API we present looks like you add Easy handles to it, but under the hood you're really adding a clone of the Share reference to the Easy handle. So each Both If users want a lock-free Share for single-threaded use, it may be better to create a totally separate The docs are not clear whether it is safe to set As a user, I might expect using the API to perhaps look something like this: let share = Share::builder()
.dns()
.psl()
.build();
let easy1 = Easy::new();
let easy2 = Easy::new();
easy1.set_share(&share);
easy2.set_share(&share); Note that the docs do indicate that the following can not be used in a multi-threaded context, even if locking is configured:
I guess that does make me wonder if actually a |
Thanks for getting back to me so quickly, and for sharing your thoughts. The API design looks very similar to what I had in mind.
Yes - after opening this issue I came across this message which actually makes it sounds like offering Given this, let me first run some tests to see how much value this adds over the caching built into multi. Specifically I'm wondering if DNS and SSL contexts are cached by multi - the documentation isn't entirely clear on that if I remember correctly. |
Yes, certain elements are already shared between handles that are added to the same multi, which IMO also limits the usefulness of the Share API if Multi does some of the same things. The Everything Curl book says:
This does start to refresh my memory of the last time I interacted with this API, and decided it actually wasn't all that useful. |
Hi, thanks for maintaining this package. I'd like to add support for the share interface - that is,
Would you accept a PR for this, and are you interested in discussing API design and implementation details?
The text was updated successfully, but these errors were encountered: