> The logic in your loop will try and submit... Ah good catch with the `while workID < NSUBMISSIONS` submission loop, Thank you! I tried too hard to make a tidy minimal example and introduced this bug thinking I could get rid of my break condition for cleanliness. Edited the code and output above to reflect this fix.
> The thread.output.tryRecv() can run before individual threads are finished. > You would need to keep track of the finished threads, and keep retrying the > unfinished threads. # Digging into `tryRecv()` So my understanding is that the whole point of tryRecv is exactly that it _can_ run before threads are finished, and it will tell you in the `dataAvailable` field if a message was received or not. So what I do is poll the thread pool until I find a thread that has indicated it is ready for more work. In this way I am tracking what threads are finished and querying them the next time I ask around the entire thread pool. I'm apparently blind to my own code by now so if this is not what I've written in code, then please tell me. Other understandings I have of `tryRecv` that might be wrong: `tryRecv` empties the message in the channel, so it cannot receive the same message twice. Also, channels are atomic, so a thread writing a message and another thread receiving a message on the same channel cannot have a race condition. `tryRecv` result field of `.dataAvailable` will be true when a message was successfully read and emptied from the channel.
