3 ms·
Not just that, but the scaling problems with threads are usually massively overstated. It's true that thread switching has quite a bit more overhead, but it's b
by Quekid5 3y ago
Not just that, but the scaling problems with threads are usually massively overstated. It's true that thread switching has quite a bit more overhead, but it's been optimized a lot since the bad old days of 15+ years ago. (Plus, unless you're using a massive number of threads it's very unlikely that thread switching is going to be your bottleneck.)
- jeffreygoesto 3y agoUnless you're on QNX 7 of course...
- Quekid5 3y agoSomething something exception that proves the rule? I'm not familiar with QNX other than knowing that it is a an RTOS... which I imagine imposes some constraints that complicate things quite a lot?
- jeffreygoesto 3y agoIt runs in millions of cars and other embedded systems, not that niche tbh. Your "exception" is the rule for a lot of engineers. But yes, they took pride that process switching is as efficient as thread switching which is a slick way of selling that they never optimized threads to be better, unlike Linux. Until QNX8 there is also the "big kernel lock"...
- Quekid5 3y ago> It runs in millions of cars and other embedded systems, not that niche tbh. Linux (in some mutilated form) runs on billions of devices. Hell, even JavaME does; or at least did, not sure what current status is. That's not really a worthwhile comparison. My 'niche' mention was in relation to number of devs who'd be familiar with it. > Your "exception" is the rule for a lot of engineers. Now, that's a fair comparison... but I wager "a lot" is still not nearly the number of engineers/devs that work with e.g. Linux. That's not to cast any aspersions, of course. After all it's often not really a choice of the engineer's part. Not sure how we got to this tangent, tbh.