When you work with sockets, you notice that many of the functions that you use, will block the rest of the program at times when you need to proceed.
This can be easily resolved by creating a new thread.
But then I read that you can also solve it through “async” programming (apparently it’s not the same thing)
Async will allow you to proceed with the program, and once a previous function has been completed, you will receive a notification about this, so you then can handle it appropriately.
Now I wonder … how is this(async) not the same as multithreading? How else can the program keep track of an earlier function while continuing with the rest of the program?
Yes, the principle is the same, but the execution is different. With threads you can basically run multiple programs in parallel and decides what happens in each of them, while with async you do create a new thread, but that has a single purpose if fetching some data for example, and then it returns that to the main thread and is destroyed.
So basically managing the threads gives you more freedom, but async is easier because you don’t need to worry about stuff like race conditions.
Okay. So if I call a function that does something that never ends, but yet it can return straight away, then it probably starts a new thread before it returns?
Another thing I’ve been thinking about. Paralell / multi-threading programming, does it really happen at the EXACT same time, that the program is all over the place at once, or is it being scheduled in some way?
Most functions aren’t started in new threads. It’s just some very specific functions. For example, in javascript most AJAX calls will be asynchronous. A new thread is started to fetch some data, and then the calling thread can fetch that data later. Basically all functions you write yourself won’t be asynchronous and will just run in the main thread.
Both
Suppose I have a CPU with 2 cores (i.e. dual core) and my program has two threads, then those thread might get assigned to the different cores and they can truly run in parallel, one thread on one CPU core, the other thread on the other CPU core. If I run this same program on a computer with a single CPU core then it can’t run truly in parallel and the OS will schedule them interleaved on the single CPU. And indeed that also means that the computer with 2 CPU cores will be twice as fast running the program1.
So basically it comes down to how many CPU cores you have, how many threads need running, and how the OS is managing all that.
1 Assuming the program is CPU bound; if it’s IO bound (meaning it needs to wait for disk read/write or network read/write a lot) than it won’t matter how many cores you throw at it, waiting is waiting, more cores can’t wait faster.
So if I create a website that must be able to handle 50,000 requests at the same time, then I will not have a positive effect if I had a thread per client if the computer / computers can not handle that much at the same time. So in this case, the computer / servers will solve it by scheduling all the threads instead, and it does not sound like a good solution, the whole thing will probably run even slower then.
I have looked closely at winsock IOCP. Do you know if there is any other server setup for windows suitable for high traffic website?
There are only so many requests a single computer can handle before everything starts to bog down. The best course of action is then is to throw more hardware at it, as the time you’ll need to tune it will cost you way more than an additional server.
