The next topic will be great, I'm coding an app which uses shared state and it's hard to work with library structs that aren't Send+Sync. Nice video as always
Thats a bad library if their types use some !Send cell and they don't have a feature to make it into a mutex instead. Same thing if they use exclusively Rc with no Arc feature
Awesome video, if you were trying to utilise threads to the maximum level would you need to do some sort of logic to get the users specs of machine and how many threads their system is capable of etc? I honestly don't have any experience with threads or really much knowledge of the underlying processes of a CPU etc and if it does differentiate between machines etc... Is this knowledge needed? and if so do you have any places to look to learn more about these ideas? Thanks for the videos I've only recently found your channel but everything I have watched so far has been really valuable.
Improving execution performance can get really technical and expansive really fast. There’s even techniques like loop unrolling to help speed up the current process of execution rather than trying to use threads. This article could give you ideas of what to look into next blog.mineiros.io/how-to-use-multithreading-and-multiprocessing-a-beginners-guide-to-parallel-and-concurrent-a69b9dd21e9d
@@TheDevMethod Awesome response thank you, I am very new to this area so apologies if my question wasn't great I'm just trying to get as much information as possible. Keep up the great work :)
What happens if that thread you are sending messages to, is really busy. Will messages be dropped or will the sending wait. Is there some sort of acknowledge?
The docs explain that the send method returns a Result that can be a SendError doc.rust-lang.org/std/sync/mpsc/struct.Sender.html#method.send. And that error comes from the receiver that disconnected while sending. doc.rust-lang.org/std/sync/mpsc/struct.SendError.html.
I mostly work with async runtimes in Rust - which is usually within the “futures” crate. The mpsc channel has back pressure support and let you define either the channel should have certain size of a buffer or “unbounded” channel that put developer in charge of make sure the channel won’t be crowded. Hope this helps.
