> For example, in a typical event driven architecture where you have worker threads running each on separate core, there would be something to decide where the

> For example, in a typical event driven architecture where you have worker threads running each on separate core, there would be something to decide where the task is queued and usually the logic will take into account how busy particular worker thread is. Wouldn't that work well only if the time taken by each task is predictable? I.e. you mention working on a trading system. But in a trading system you want to run the same branchless code path regardless of the kind of incoming event and whether you are sending an order or not after running the trading logic. So the individual "task" is very predictable. On the other hand think of a task like "return all the comments for a certain page". The time taken by an individual task is unpredictable, proportional to the number of comments. So you'll regularly get one core getting enqueued a bunch of tasks with no comments, finishing quickly and then staying idle. With work stealing, after finishing, that core would get a chance at "stealing" tasks from other threads' queues. (of course, the architecture I am describing would be awful for a trading system) > The operating system does nothing in this case, what it sees is a number of threads each running on its separate core that don't need to be preempted (hopefully). Btw, I agree that pinning OS threads to each core and then layering something of your own on top of it is going to be faster. It is just that you can layer on top a green thread system (like Go), and get something thread-for-request -like.