Rust

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. We now have a generic IdManager so now we just need to finish off the required functionality. The missing pieces are: a “reuse policy”, so we can dictate how new ids are allocated the ability to restrict the range of ids used. the ability to mark some ids as used The first of these is to allow us to use the id range “in order” before we start using ids that have been returned to us.

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. Now that we have an IdManager that works reasonably well and does much of what we require of it we can look at how to make it a bit more flexible. At present the IdManager can only provide Ids that are BYTE sized. I’d like to make it a generic type so that we can specify the data type to used for the Id that is provided.

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. We now have a ThreadSafeIdManager that can provide SmartId’s. It would probably be better to simply have an IdManager that provides Id’s, especially since, in Rust, we can’t even reliably use the original IdManager implementation. I’m adverse to renaming the code at this point as that breaks the ease of comparison with earlier versions.

Previously published This article was previously published on len-learns-rust.com. A full index of the articles from this len-learns-rust.com can be found here. The simple id manager that I built last time is just that, simple. However, it’s enough to start exploring some more complex ideas in Rust. With the current interface you can allocate an id from the id manager and never give it back. In fact, it’s easier to do that than it is to use it properly and always give the id back when you’re done with it.

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. Now that we have a collection of intervals we can begin to build our id manager. The id manager turns the collection of intervals on its head a bit in that the intervals represent the available ids, so the manager allocates an id by removing it from the collection. The simplest id manager looks a bit like this:

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. Now that we can insert intervals into our collection we need to be able to remove them. There are three ways to remove values from our collection: remove the first interval in the collection remove the first value in the collection remove an arbitrary value from the collection The first is the easiest and the following tests show how it should work:

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. Our simple collection of intervals has a major failing, it doesn’t merge intervals and so we end up with as many intervals as we perform insert operations. For example, if we start with an empty collection and add [4] and then [6] we should have [4], [6], which we currently do.

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. Now that I have a simple interval I need a collection of them to represent the available ids that we can allocate. I’m going to create a new file for this new struct, intervals.rs and move the code from last time into interval.rs. I realise that I could leave it all in lib.

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. We’ll start with an interval, this is a struct with an upper and lower limit and represents an inclusive range, such as [0,255] or [1] where both upper and lower are the same value, 1. I’m sure there’s a better way to do this, such as using std::ops::Range<> but for now this is nice and simple.

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. The first piece of code that I’m going to play with in Rust is a “reusable id manager”. This is a collection of numerical ids which can be allocated, used and then released back to a pool for later reuse. I tend to use this kind of code for network protocols where something like a peer-id is required; these ids can be within a given range (usually limited by the data type that represents them), and are “in use” for a period of time and then return to the collection.