so as a wanabee safe app maker I have been experimenting with safe web apps, but so far I completely ignored freeing handles.
I am studying some examples, and I notice that , for instance, the getMessages function in chaty by @Joseph_Meagher frees the entries and data handles at each call ( main.js , l 62-63 )
I am asking myself if it is important to free the handles each time they are used, which implies fetching them again at next call, thus stressing the network.
Could it be a good thing to store the handles for the whole session ? ( I mean, those that do not change , eg : appHandle ) I guess it implies either using higher scope variables or passing them to the functions that need them.
Yes, it is better to keep those handles you would reuse for as long as you need them. Note that getting new handles doesn’t necessarily imply that there is a network activity, e.g. when you create a Mutation and apply mutations to it, this doesn’t go to the network until you actually apply the mutations to a MD.
As you point out, the appHandle is very likely to be needed for the whole app’s lifespan.
There’s also a danger, which I’m currently ignoring, that by not freeing them or keeping track of them , you gradually use up memory and things begin to break eventually.
I also think (awaiting correction) that there may be differences between using one part of the API and another (safe_nodejs / DOM / DOM safeNfs) in terms of network activity when calling a single API method. For example, some API methods may commit immediately, while others remain pending until the commit is triggered. I could be wrong about this!
At some point these details will need clarifying, but for the time being ensuring they are freed at some point should be seen as a minimum, while keeping them around for re-use is always going to help rather than hinder speed, though not necessarily a big deal in many situations.
Note that they all get freed if you free the app handle, so not necessary to free each one if you ever free that. Also, all are freed when the page is refreshed, tab closed, browser shut down etc.
The main reason I did that was because I wanted the code to be modular and contained, so everything to do with getting messages stays in get messages this means if you wanted to you would be able to copy the getmessages function put it in another project and then use without further (or much) modifications.
It would be possible to request the Mutable Data Handle in the first function and pass it along but that would make the code a bit harder to read and more complex, another thing to note is chaty uses two network states: connected and authorised, it only authorises if it needs to send a message but this means it would have two app handles so you would need either free the orginal md handles (sometime before authorising) in the authorise function or as I did at the end of send and getmessages function
Also it works as a nice example showing freeing handles in use and the less global variables or handles in use the better as @happybeing said
now this will take a good a while on computers but once you start working with mobile devices (especially lower end models) you may have to keep this in mind.
P.S.
When you free a handle the reference is freed from memory and you are then able to make another handle of the same type of resource.
This reads as if you can’t create a second handle for the same kind of resource - do you mean that? I wouldn’t expect that to be the case (but don’t know for sure). I expect that once you have a handle you can use it (and others of the same type) until it is freed.
I think so, I am pretty sure it applies to the app handle anyways but most of the documentation needs to be verified. I’ll put up a todo in the meantime.
I don’t think this is true, at least I cannot remember any case like this, is there any particular case you suspect this?
Although it is true that in a couple of cases like the DOM APIs to authorise and connect take care of some steps internally which would need to be handled explicitly by a nodejs app, but I think this is only the case for the authorisation and connection steps.
yes, this is what I have been feeling when reading your code : creating the handles at each call makes it really easy to read, these are just simple functions without parameters.
Indeed, if we imagine ( I do ) a version that uses several mutables, for instance messages in various topics, then your functions can be easily reused with little modification and great readability.
I am trying to figure out how to handle the 2 states ( auth / no auth ) and keep everything simple. your solution looks clever in this aspect !
Thank you very much for exposing your intentions, this really helps a lot in the process of learning.
I foresee this same problem. I’m writing a website App that will upload Immutable files to one container, but then manage metadata about those files in an Immutable file in a different container… at least that’s the theory when we have more containers. I don’t know when the user is going to close the App’s tab.
My current approach is atomized API calls: the user wants to add an Immutable file? New app handle, new permission check (specific to adding files in one container), new everything. Upload the file. Free everything. While still on the same page, the user now wants to update information about that new file in the Mutable file? New app handle, new permission check (specific to mutating files in the other container), new everything. Update the Mutable file. Free the handles.
Given the current API, I just don’t see how to avoid atomic calls without bloating RAM. I cannot possibly predict whether or not the user is going to randomly close a tab without clicking the right button to free all the handles that I should be reusing. Instead of relying on that, I’m going atomic and freeing them as soon as the atomic transaction is complete.
I think there needs to be way more documentation or discussion about the dangers of freeing vs not. I’m not seeing any numbers to justify any approach, so it is really unclear to me how anyone is reaching their conclusions.
PS I come from a background with C malloc() and free(), so my thinking in my previous post is along the lines of that background: it’s always easy to leak memory and so it takes rigid discipline to keep all your memory in check.
I don’t think there’s much to debate - you can ensure memory is freed and you will be fine, and if you don’t your users may run into problems. How soon and what the problems are will be dependent on the application and how it is used.
Edit: oh, I think you mean whether to free immediately or not. In which case, I think that’s going to be something to test with particular applications in the first instance.
It is indeed a discussing worth having one see have some comparison data.
, you gradually use up memory and things begin to break eventually.
) a version that uses several mutables, for instance messages in various topics, then your functions can be easily reused with little modification and great readability.