No problem, glad to help. :)

Okay, I know I am late to the party here and might be a voice in the wilderness, but I think for your case, using manual multi-threading is exactly the right way to go. Why? Because you are teaching, students need to understand the complexity of the underlying functionality to be able to know when it is appropriate to use the simplified interfaces that modern languages, libraries, and syntactic sugar have added over the last thirty years. One of the things that I see in code that has been written by people who just discovered the async calls or the Thread library in whatever language is hot with management is the overuse of threads. They throw calls that are absolutely sure to block right here right now into a separate thread, even though processing on their application can not proceed without the answer. Hey folks, all of our operating systems and most of our language runtimes are smart enough to detect when some thread/process goes out for a long IO operation and let something else use the CPU. There is no need to add the overhead and complexity of putting your IO into a thread. On the other hand, beginners often miss thread operations in large complex compute operations. Activities where spinning the processing of a security token or hash into a temporary thread on a different core/processor thread with an async callback would let the other pre-authorized operations start rather than blocking on that operation. So, in addition to teaching them about the complexity of the dance that happens behind every simple thread spawn, you can also give them some views into the differences between appropriate and inappropriate times to use threads. Why the specific example is a teaching only example, and what real use-cases would be. Just a thought.