The website work with Hugo that I mentioned here is now mostly complete. I’ve managed to find a Hugo theme that worked for me and tweak it so that I could keep the shape of my sites pretty much the same. I’ve now updated this site to match as this format is more suitable to my “blundering about whilst learning” style. I’ve added some chapter categories so that I can still read the key parts of my learning experience in the correct order.

I’m currently reading Rust Brain Teasers by Herbert Wolverson. It’s a nice book of bite-sized puzzles in Rust that are ideal for the way I like to learn (randomly jumping around from subject to subject that happen to interest me). Each puzzle presents some code, asks you what you think it does and then shows you the hidden complexity. At the end of each section are some links to further reading.

I’m currently reading Rust Atomics and Locks by Mara Bos and it’s excellent. Really aproachable, concise and detailed. A pleasure to read.

As I said when I started this site, part of the reason for this was to learn enough Hugo to be able to rework my older websites and move them away from Movable Type. This work is now under way and it means that I’ll be blogging less here for a while. I have several sites to update: https://lhexapod.com - my old adventures in robotics site https://lockexplorer.com - a site that needs to be shut down as the tools I used to sell have been discontinued.

Now that I have my generic IdManager I’d like to use it from multiple threads. As I said, this code would normally be used for things like connection ids for network protocols and I’ve spent the past 20 years or so writing servers that use small numbers of threads to handle many thousands of connections with work for each connection being given to a thread from a thread pool to perform.

I’ve now built a generic IdManager which does everything I want it to do, for now. I’ve bumbled along in a very non-scientific manner, mostly using the compiler errors to guide me towards things I’ve then looked up on the web. The code works and is tested but it’s now time to go back to the books with a series of questions that this journey has got me thinking about:

We now have a generic IdManager so now we just need to finish off the required functionalityrequire of it. The missing pieces are: a “resuse 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.

Now that we have an IdManager that works reasonaly 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. Generic code in Rust can look a little similar to generic code in C++, they both make extensive use of angle brackets, however Rust generics are much more precise; though C++20 has constraints and concepts which do a similar thing to Rust Trait Bounds, but more on Traits later… Our first attempt at generic code in Rust might look something like this, if we start with making just the Interval generic:

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. I could, of course, shuffle all the code around, rename files and change modules but, to be honest, the whole module structure is also a bit unwieldy at present.

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. The usual way of addressing this issue in C++ is by using the RAII1 pattern whereby a separate object becomes responsible for the lifetime of the resource.