: thread rant [semi-OT]
[...]
Can we do better? Yes, thanks to various programming techniques that allow
us to keep more of the system busy. The most important bottleneck is
probably the network - it makes no sense for our server to wait while a slow
client takes its time acknowledging our packets
On Sat, 2 Sep 2000, J. Dow wrote:
> Dan, another thing to consider with multithreading is that it is a way
> to avoid "convoy" effects if there is a nice priority mechanism for
> first in first out messaging. [...]
yep, this is a frequent problem at the level of the kernel. We fixed such
a
> In summary, when "multithreading" floats into your mind, think
> "concurrency." Think very carefully about how you might simultaneously
> exploit all of the independent resources in your computer. Due to the long
> and complex history of OS development, a different API is usually required
> to
> All portability issues aside, if one is writing an application in
> Linux that one would be tempted to make multithreaded for
> whatever reason, what would be the better Linux way of doing
> things?
Let's go back to basics. Look inside your computer. See what's there:
1) one (or more) CPUs
2)
: thread rant [semi-OT]
[...]
Can we do better? Yes, thanks to various programming techniques that allow
us to keep more of the system busy. The most important bottleneck is
probably the network - it makes no sense for our server to wait while a slow
client takes its time acknowledging our packets
5 matches
Mail list logo
