ubject: Re: 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 o
[EMAIL PROTECTED] (Dan Maas) wrote on 02.09.00 in
<020d01c014a9$f48d3fa0$0701a8c0@morph>:
> When people think of "multithreading," often they are just looking for a way
> to extract more concurrency from their machine. You want all these
> independent parts to be working on your task simultaneo
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 (lon
> 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 c
> 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)
5 matches
Mail list logo
