because the Java language lacks an interface for non-blocking I/O threads are especially necessary in constructing communications intensive applications in Java
Wouldn't it be easier to add an interface for non-blocking I/O to Java??? Err - isn't it supposed to be an inherently multitasking language? Sheesh. This is an excellent example what's wrong with Sun's dog-in-the-manger attitude to the Java spec. "We already defined that, it can't be changed, fix it some other way! No, we're too busy defining new multimedia api's to take a look at it"
I can't say for certain, but I suspect non-blocking I/O isn't available because operating systems that aren't unices don't necessarily support it. Plus, recall that the only way to efficiently use non-blocking I/O is to select the file descriptors to wait on. This is tricky enough that making threading easier was probably the right thing to do.
That said, the fact that Java makes threading syntax, at least, easy is a bit scary. Java makes it easy to spin up multiple threads, but the underlying problems (deadlock, starvation, etc.) with multithreading still exist. Simply throwing synchronized here and there isn't magic, and will substantially slow a program when used unwisely.
Using threading safely means isolating the portions of code that have to be multithreaded to the bare minimum - i.e., at points where message passing occurs. And yet the "it's easy, just spin up a thread!" mentality is found in many books/tutorials, etc. Scary.
But this was a general interest article...
on
The Life of Linus
·
· Score: 1
Those who don't get the Merc might not realize that this wasn't a story buried in some tech section somewhere, but rather the cover story of the Sunday magazine portion of the paper (local equivalent of Parade, but much better - how could it not be?) Imagine my surprise at opening my Sunday paper and finding Linus' smiling, hot-tubbed mug.
As such, this was an article for the masses; the Slashdot crowd was definitely not the intended audience. Not everyone in San Jose is a software nerd, you know. Just more than average.
Apart from the obvious Apache == Linux version mistake, I thought it was a decent, interesting article. It was great to hear Linus bitch about the outrageous cost of housing, when I have the same problem.
People who call this sort of thing hero worship might be right, but I'd suggest that anyone looking for a hero could do much worse. Linus hasn't gained fame on the backs of others, hasn't said one thing publicly and done another privately, in short, he hasn't aspired to fortune or fame. The guy's got his priorities straight - love your family, do what you love to do, and let the rest fall where it falls. How refreshing.
Check out the Stennis space center website, as referenced in the CNN article. They've got some quite cool closeup footage of SSME (space shuttle main engine) test firings. Impressive stuff, even if the tech is old.
Apparently you can even observe test firings, if you happen to find yourself in the middle of Mississippi nowhere with nothing better to do.
I would suggest that writing code that is both clean and tight is possible, but extremely difficult - as it hinges upon getting the design just right. A great design will practically write clean and tight code for itself, assuming a competent coder.
Of course, getting the design right almost never happens the first time, and is nearly impossible while specifications and requirements are changing underfoot. In most real-world situations one almost never gets a chance to fix the design.
Given an imperfect design, one can write sneaky, impenetrable, yet tight code, or can keep things relatively clean -- and pay the price in bloat.
Slashdot Mirror
I can't say for certain, but I suspect non-blocking I/O isn't available because operating systems that aren't unices don't necessarily support it. Plus, recall that the only way to efficiently use non-blocking I/O is to select the file descriptors to wait on. This is tricky enough that making threading easier was probably the right thing to do.
That said, the fact that Java makes threading syntax, at least, easy is a bit scary. Java makes it easy to spin up multiple threads, but the underlying problems (deadlock, starvation, etc.) with multithreading still exist. Simply throwing synchronized here and there isn't magic, and will substantially slow a program when used unwisely.
Using threading safely means isolating the portions of code that have to be multithreaded to the bare minimum - i.e., at points where message passing occurs. And yet the "it's easy, just spin up a thread!" mentality is found in many books/tutorials, etc. Scary.
As such, this was an article for the masses; the Slashdot crowd was definitely not the intended audience. Not everyone in San Jose is a software nerd, you know. Just more than average.
Apart from the obvious Apache == Linux version mistake, I thought it was a decent, interesting article. It was great to hear Linus bitch about the outrageous cost of housing, when I have the same problem.
People who call this sort of thing hero worship might be right, but I'd suggest that anyone looking for a hero could do much worse. Linus hasn't gained fame on the backs of others, hasn't said one thing publicly and done another privately, in short, he hasn't aspired to fortune or fame. The guy's got his priorities straight - love your family, do what you love to do, and let the rest fall where it falls. How refreshing.
Apparently you can even observe test firings, if you happen to find yourself in the middle of Mississippi nowhere with nothing better to do.
http://www.ssc.nasa.gov/lines/propulsion/
The quoted 70 Mpps is for raw polygons (one color value per poly). I believe I read that the textured, shaded poly rate is more like 10 Mpps.
And of course, as others have pointed out, you have to divide that number by however many FPS your brain requires to interpret smooth motion...
Of course, getting the design right almost never happens the first time, and is nearly impossible while specifications and requirements are changing underfoot. In most real-world situations one almost never gets a chance to fix the design.
Given an imperfect design, one can write sneaky, impenetrable, yet tight code, or can keep things relatively clean -- and pay the price in bloat.
I would much rather maintain the latter...