Rust - Accessing the Id Manager from multiple threads

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. Since I now understand a little about how to share data between threads I can try and use my Id Manager from multiple threads. Following the same pattern as I’ve been using with the other threading code, something like this might work… #[test] fn test_channel_thread_with_id_manager() { let id_manager = Arc::new(IdManager::<u8>::new(ReuseSlow)); let shared_manager = Arc::clone(&id_manager); let data = Arc::new(Mutex::new(HashMap::<String, Id<u8>>::new())); let shared_data = Arc::clone(&data); let mut thread = ChannelThread::new(move |message| { let id = shared_manager.

Rust - Sharing data between threads

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 send messages to threads I want to see how we can access shared data from those threads. This isn’t the best design choice as shared data needs to be protected by locks so that it is accessed in an atomic fashion and the various threads involved with this data will contend with each other over the locks.

Testing, discipline and detail

The manual process around updating broken links is due to be replaced by a simple link checker that I’ve been writing in Rust. It’s not quite ready yet but it’s nearly there… I was updating a few broken links today and came across this from 2004; “Software development is about discipline and detail; code quality starts to decay as soon as developers forget this. All code decays, but tests can help to make this decay obvious earlier.

Rust - Simple threading

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. The simplest threading is already covered by most Rust books. Starting up a thread, passing stuff to it, letting it run and waiting for it to finish. Something like this is the basic thread example in Rust. This work’s and is easy to understand and reason about. The spawned thread clearly runs for less time than the main thread as we join with it before the main thread completes but we rely on the spawned thread to decide when to shut down, this isn’t that important here as the spawned thread has a finite amount of work to do, but for threads that do a potentially infinite amount of work I will need a way to ask the thread to stop…

Rust - Thinking about threading

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. My threading background in C++ on Windows and Linux goes back a long way and that means that I have some set ways of doing things that may not map directly to the Rust way of doing things. I tend to use threads with the following patterns at present: A thread starts up, waits on one or more externally controlled ’events’ and, when one of these is triggered the thread does something, or shuts down.

Wayback

This blog has been around a long time and the internet tends to rot. This means that quite a lot of the links on old posts are broken. I’m slowly fixing these broken links to use “The Wayback Machine” but it’s complicated to automate as the resulting URLs need to include a timestamp of a valid snapshot and can’t just include a ‘rough idea of the date’. So I’m fixing the broken links manually by watching the posts that are accessed the most and manually checking the links and fixing them up.

20 years of blogging...

On the 3rd of May 2003 I posted the first entry on this blog. I then proceeded to “back fill” the blog with various things that had either been posted before in other places or had been laying around waiting for me to have somewhere to put them. This is why although the blog began in 2003 the archives go back to 1992. What I said on the 10th anniversary of this blog is still apt:

Adventures with \Device\Afd - test driven understanding

I’ve been investigating the ‘sparsely documented’ \Device\Afd interface that lies below the Winsock2 layer. Today I use a test driven method for understanding and documenting the API. TDU - Test Driven Understanding When trying to understand a new API I always like to end up with executable documentation in the form of tests that show the behaviour of the API. I write these tests in the same way that I write any tests; writing a test that fails and then adjusting so that it passes.

Quick and dirty analysis of memory allocations in Visual Studio code

Yesterday I was bemoaning encapsulation and how it was hiding what was going on inside my objects (and quite right too, what good would it be otherwise?). The issue is that the object I was interested in, and each of the objects that formed it, were allocating more memory that expected. It wasn’t so much that the object was bigger than expected, just that there were more allocations than I expected and that for some reason destroying lots of these objects is taking longer than I would expect.

The cost of encapsulation

I’m debugging performance issues with a C++ server that has been stalling and then failing to recover. I’ve reached a point where we can generate the problem using a network interruption that causes multiple connections to disconnect at the same time. The fixed sized thread pool that services these connections becomes overloaded with work that requires it to clean up connection objects for the disconnected connections and all of the threads in the pool spend far too long fighting over the lock to the heap as they try and return memory to it to clean up the connection objects.