Data handle (handleId): why?

I’m following the Email app tutorial but there is one thing that I can’t understand: why is there this “data handle” thing? Why not just use the “name + tag”?

As far as I understand, DataId commands don’t interact with the network, but rather, they only interact with the launcher / FFI libraries. They are a sort of helper methods. I believe that each SD/Immutable/Appendable command needs to allocate memory and do some transactions that can be optimized with this approach, but I’m afraid that this can lead to memory leaks on websites.

Unless I’m missing some point, this brings to the average JS developer the same risks of using a memory handling language, such as C. We know that it is easy for very good developers to create memory allocation related bugs, that’s the main reason why Rust was created in first place, so imagine this power given to the average web-developer. It won’t be a surprise if mostly safe sites don’t free these handlers after its use, leading to memory problems after some time navigating through safe websites.

Sorry if misunderstood this feature, I hope that I had and I’ll be glad if someone clarify it to me :wink:

PS: I don’t know where to put this question. Is it here or on the safe dev forum?

2 Likes

In the Low Level API RFC

Notice how majority of operations is now in safe-rust. Further, we use LruCache so that if a misbehaving app does not free resource (does not call destroy()), we make sure there is no indefinite memory leak as LruCache will clean up unused objects once its capacity is filled. Storing AppHandle in Option (AppHandle) will give us nice statistics and profiling to find apps that leave maximum amount of uncleaned objects when memory footprint starts growing and we make a scan of our object-cache.

1 Like

Sounds very technical, so I think its best for you to put it on the dev forum. More people who actually know about the code will see it, I guess.

4 Likes

This is how the API internally works right now in safe_core. This is what it looks like internally in the rust-process when you actually do NFS or DNS tasks. In order to allow more apps to have more fine-grained-control (hence the name LOW_LEVEL_API) to be able to show-case some cool apps (like the Email or Blog app), we decided to go the quick route and just expose the API as it exists for now.

I, and many others in the team, full heartely agree with you that the file-descriptor-API doesn’t really feel very well desigend, especially for a REST-Interface, and it does indeed lead to internal memory-leaking should an App (for what reasons what-so-ever) not do the proper release calls. In fact, I have on my To Do-List for this week to bring up an alternative proposal API to replace this current version before v1.0. I’ll post that on the devforum in due time.

I’d say the dev-forum. It is very API specific and is of technical nature.

3 Likes