Matthew Weigel wrote:
Geoff Steckel wrote:
I'm sure you're extremely bright and can do it.
It's not about me. If the OpenBSD developers *can't*, they should just
drop any efforts to refine the big SMP lock, any effort to provide
kernel threads, any effort to make libc reentrant.
And if they do that, then a) threads will have zero performance value,
but b) splitting work across threads will have minimal performance value
too.
To put it another way, if they can deal with it in the kernel, if they
can deal with the vastly wider array of security problems that can crop
up in device drivers... they can handle multi-threaded application code.
That argument is not good engineering.
Use maximum effort at the point of maximum return:
Develop the kernel SMP and process handling code so that
it works very very well. Debug it once.
Everything else uses those resources.
Don't waste time reinventing the MP wheel in applications code.
Don't add work that doesn't need to be done.
Don't add work that doesn't add any significant value.
Don't add work that adds avoidable risk.
That is engineering.
It is the art of the possible.
What is the best that can be done with the resources available.
That is judgment based on centuries of experience in many forms of engineering.
Using judgment, measurement, history, and proven heuristics is engineering.
Software is not magic. It cannot ignore those rules.
If you apply these rules you will get good results.
If you do not, your projects will cost more, take longer,
and have worse results.
It's that simple. It's engineering.
Don't take my word for it.
Talk to a successful electrical, mechanical, etc. engineer.
Don't talk to a "software engineer". There aren't any.
Don't talk to a "computer scientist". They know nothing about
engineering. (Or , for that matter, human factors)
You will learn a lot.
If you don't bother, you're a troll.
Bye.
