-
Notifications
You must be signed in to change notification settings - Fork 8
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
Should inputs and outputs be tied to the transaction? #45
Comments
I tried to improve memory allocations but it is actually super complicated. The problem is that every object seems to live in a scope and it actually depends on the method call and therefore Dispose does not really help. lets take output as an example:
We could avoid the problem with the output by resolving all values directly, but this would hurt performance, especially for events. So on idea would be to have scopes, which are>
Every object is a resource and has a reference to a scope. Once a scope is over it releases all children and makes them unusable. If you use any method a ObjectDisposedException is thrown. |
Hi, @SebastianStehle! About this:
Yes, that's true. But I'm working on multiple improvements to the memory management of the library to free resources via finalizers. Right now, every exposed resource that can be disposed implements So, this means that today if the client of the library doesn't dispose the
It's not obvious, but the idea of the This could probably be mentioned in the class documentation.
I'm afraid that's not the case. The documentation of yffi mentions that, for example, an Also, every
Unless we really need to do that, I'd rather not take that approach. The idea of this library is to be a thin layer around Yrs, so I'm always trying to write the least amount of code and make sure it works as it should. In this case, the memory management seems to work well by just calling the necessary
While developing that class, I thought about it, but I didn't do it because:
So, because of that, I suggest we keep giving more control to the client code and only trigger code to read values when they're requested (if that's possible, like in this case).
That's right. It should be done after #34.
That's already handled by giving a "flag" to every new
Let's take the map iterator as an example, whenever the library requests the next entry, it should store the pointer and call This is documented in the
Please, check if the mentions I added above help alleviate the problem you mentioned. From my point of view, there's no need for us to write extra code to handle memory management except for calling the Yrs If I missed something here, please let me know and I can re-evaluate this comment. |
I came to the same conclusion now with finalizers. In my own fork I am going for a simplified approach for now, that does not need dispose at all, because almost all memory can be released immediately. If you want to keep the output you need a reference to a resource owner to keep the resource owner alive, otherwise something like that could fail:
|
Hi, @SebastianStehle! Same as other issues in the repo, I believe this one can be closed now that we merged #55, right? |
Some inputs and outputs allocate memory, which has to be freed again. Afaik this does not happen automatically. Therefore every input needs to be released again after the transaction has been completed.
This causes 2 issues IMHO:
output.Collection
oroutput.Array
where you have to loop over the outputs manually and dispose them.So in general there are not hat much uses cases ,where an input and output needs to live outside the transaction.
What I recommend is the following:
The text was updated successfully, but these errors were encountered: