-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
ARC API cleanup #4292
Comments
Regarding ARC's get() function, yes, I meant to replace that with a method but never got around to it. Same for clone() and unwrap(). As for MutexARC, I'm of split minds. I called it "access" to contrast with the read/write functionality of RWARC -- no matter what you're doing with the data in a MutexARC, the lock is held in the same mode, whereas with RWARC, readers can read simultaneously. And MutexARC is unsafe, whereas RWARC is safe, so on one hand I'd say if you need different read and write functionality you should be using RWARC instead. On the other hand, the reason MutexARC is unsafe is to allow for nesting more ARCs inside of them, which RWARCs can't do. So adding a read() function to MutexARC would allow constructing, e.g., a LinearMap in an ARC that stores more ARCs inside of it, which would be crazy, but also awesome. Anyway, if MutexARC gains a read function, make sure the documentation stresses that it's not there for parallelism. |
There is probably a mismatch between what arc provides and what people want to do. For example, in my case I didn't want write access at all, but my data was not Const. So MutexARC was my only option. |
Using MutexARC for read-only access to non-Const data strikes me as treating the symptom rather than the disease. MutexARC incurs a lot of runtime overhead (constant-time, but several pipe reads and writes) doing synchronisation, compared to ARC, which needs none at all. Instead, convert your data structure to have no mutable interior fields, and you can use ARC. |
Not sure it's that simple. My problem is that my struct includes closures and closures are not Const (see #3569). |
Then that is that bug's problem, not this one. ;) |
@bblum still relevant? It seems the API has already been changed to use methods |
A little bit. The constructors still need to be changed from e.g. |
The constructors have now been fixed. I think this bug can be closed; if you know of anything else that needs to be done, please open up a more specific bug. |
The text was updated successfully, but these errors were encountered: