32 ms·

Honest question: do you really need concurrency to solve problems?

• sliken 4y ago
  Today's world even power constrained devices like phones have many cores. Laptops and desktops are getting more cores just about every year. Even chromebooks are heading towards 8 cores last I heard. Take for instance wanting to backup a directory to a remote server and/or cloud. Sure you could use scp, single threaded would be fine, read a file, hand it over to scp, which does encryption and transport. However you'd waste quite a bit of network bandwidth and disk space. Ideally you want incremental, so you need a database for metadata. You could add compression as well. But you likely want deduplication so if you have a system image for a virtual machine and 1% of it changes you can upload 1%. You also likely want to detect corruption if you upload a backup, then restore and the file has changed. There are single threaded programs that do these kind of things, but they tend to be very slow, some well known backup clients that promise a flat rate for infinite backups often use the approach to reduce the amount of data it's practical to backup. So ideally you have multiple threads, one for scanning the filesystem, one for talking to a database of metadata, another for checksumming plaintext, encrypting, and checksumming the encrypted blob, and yet another for managing a queue of blobs to upload. Without concurrency even simple things like uploading backups can become painfully slow.
• jchw 4y ago
  Sure... The most obvious case is running an internet service, but if you're asking if I've ever done something where there's either a strong CPU-bound or latency constraints, the answer is "yes."