I seem to remember that even though Google was much talked about in 2000, it had yet to become the preminent search engine it is today.
Remember that Google was the preeminent search engine (as far as effectiveness) for over a year before it left "beta" status--it had supplanted Altavista and Lycos well before then among the technically sophisticated. And then note that Google dropped the "beta" label in September of 1999. By then it was clearly the market leader technologically and possibly the leader by market share.
By June of 2000, Yahoo was using Google to do all their searches and it had clearly surpassed the alternatives by market share.
So why not add your name to the dictionary (You know, Right-click, add to dictionary)? Why should a general purpose word processor ship with every obscure last name installed by default in its dictionary?
The problem isn't that it's not in the dictionary. If I ran spell-check and my name was unrecognized, I'd have no problem with that. The problem is that if I typed my name, it would silently change it to the wrong thing--so even if I'm watching the screen, it's changing things several letters back without asking or notifying me.
I have no idea if autospell still works the same way, but at that time it truly just silently mangled things.
I swear to god that guy [Bruce] hasn't contributed anything meaningful to the public since 1998 and yet he's still...there
Aside from the value of getting publicity for security issues: 1999: Solitaire algorithm published. An output-feedback mode stream cipher which can be easily calculated using a pen, paper, and a deck of cards, allowing people without computers to use strong encryption in their communications. This system was featured in Neal Stephenson's Cryptonomicon. 2003: Helix algorithm published. A fast stream cipher comparable in speed to RC4 and with low per-message overhead, making it suitable for very small messages. 2004: Phelix algorithm published, a refinement of the earlier Helix algorithm.
emusic.com. 40 MP3s for $10/month. 90 MP3s for $20/month. No DRM, excellent selection
Selection's a funny thing. You can have a ton, but unless you have what I'm looking for it's not worth much.
E.g. I just went and looked for a bunch of names (Living End, Richard Thompson, Tom Waits, PJ Harvey) and came up with a smattering of albums. The artist's most famous album was only available for Richard Thompson, and the rest of his more famous work was missing.
But there was a famous Senator Charles Sumner from Boston, who gave an anti-slavery speech in 1956 and was promptly beaten senseless by South Carolina Senator Preston Brooks--he was knocked unconscious and then unable to attend Senate for 3 years. He became the leader of the Radical Republicans, arguing for black suffrage, extreme reconstruction acts, etc and leading the attempts to impeach Andrew Johnson.
OTOH, it is one of two major things that got me off Windows back in '94.
1. I can't type my name in MS Word ("Sumner") without it auto-"correcting" to "Summer". Sure, I can dig through menus and turn that off--but when you're in school using a different computer in the cluster every day that gets to be a pain in the ass. 2. At the time, all available winsock options froze hard if I tried to open 2 simultaneous network connections.
Glad to see that in the past decade they've fixed one of the 2.
Hey I'm just some novice who's ascended 5-10 times. I have a caveman right now who looks like he's going to make it too (past the quest, pretty complete ascension kit) if I don't do anything stupid. I'm trying to do one of each class (I have archaeologist, valkyrie, tourist, wizard, priest--some of those a couple times).
The 2 mantras you need to remember are: 1. Run away! 2. Don't take risks.
I played for like 10 years before ascending, but after the first time it gets a lot easier (like 1 month between 1st and 2nd time).
Also the early game has a lot more risk of death than the late game, so if you play carefully then you might die 20 times for every 1 character who gets past the Castle, but you'll ascend 90% of the ones who get that far (you can raise that percentage a lot if you're willing to be bored to tears, which I'm not).
But the real experts are guys like Marvin--he's playing in the online nethack tournament and ascended at least his first 9 consecutive characters without a death. And some of those guys do crazy conducts (e.g. playing a pacifist who never attacks anything, which usually means relying on pets to do all the killing).
The proper name for a text-mode program that works by moving the cursor around on a text screen and taking user input direct unbuffered keyboard input (ie., not making you hit ENTER after every command), is "Roguelike". Or at least that's what ESR calls them in his book. Maybe ESR just made that term up recently
rec.games.roguelike (which includes r.g.r.nethack, r.g.r.moria, r.g.r.angband, etc) has been around since 1993 at least, and the term was used prior to that on Usenet back at least to 1989.
I prefer SLASH'EM myself, like Nethack but much, much worse.
SLASH'EM is generally regarded as significantly easier than Nethack once you learn how to play them both.
It's a lot harder when you're starting out (especially coming from a Nethack background, and learning that things like drain resistance are just as integral a part of a safe ascension kit as magic resistanc, reflection, etc), but once you've ascended a few times in each then slash'em has a lot more "outs".
Does Nethack qualify? Not quite text-only, but it will run on a terminal.
FYI.
The annual Nethack tournament is currently ongoing. Visit rec.games.roguelike.nethack for more info.
Highlights so far:
Marvin has ascended his first 9 consecutive characters (all from different classes). Rast has an ascension in 10067 turns. Most conducts for an ascension so far is 10 (illiterate weaponless atheist foodless polyless polyselfless wishless, which implies vegan vegetarian artifact-wishless).
As a result, you get tons of unstable Windows applications because to get any reasonable concurrency you have to throw out the years of hard work that OS designers put into having protected memory. Throw out years of hard work? Give me a break! It almost seems that you are blaming the poor quality of modern threaded applications on Windows! That's rich!
No, I'm blaming Windows for the prevalence of multithreaded apps that don't need to be multithreaded. And yes, using threads throws out memory protection within the application; to an extent, it's like old unprotected Mac apps grovelling around in system memory. It requires a lot of discipline, and bugs are more able to bring the whole system down--and it's a lot less secure. That said, it's still sometimes the best option. But you shouldn't be forced into it.
Concurrency is difficult to use correctly no matter what technology you use.
Absolutely. Why compound that by throwing out shared memory as well?
Inter-process shared/mapped memory is just as susceptible to race conditions as cross-thread shared memory, and inter-process synchronization logic can deadlock just as easily as thread synchronization logic. And the results are the same: once a process is deadlocked, or corrupts its data due to a race condition, what difference does it make if it's running in its own address space? The software has failed catastrophically either way!
Example: You have a helper function that does something asynchronously in your web server. Your helper segfaults when trying to read a file that's too large. Would you rather have the web server go down completely, or just have connections that try to load large files get closed?
In both cases the software has failed, but one is far more catastrophic. Obviously if you can write bug-free code then either way will work--one of the major reasons for having memory protection is that code is _not_ bug free, and when it fails you'd like to isolate the damage.
What's more, with an IPC solution you know explicitly what you're sharing; with a multithreaded solution it's a lot easier to not realize when another thread is accessing the same memory as you. It's a lot easier to introduce bugs that way, because you're sharing everything and not just the things you need to share.
Threads are certainly right for a lot of tasks, but that choice ought to be dictated by whether you need shared memory or not.
And it's not just a Windows problem. Java's worse in a lot of ways; at least, as you point out, there are ways to work around the problem in Windows. Java doesn't have any real multiprocess solution short of native extensions.
Threads certainly have a place, I never said otherwise. The problem is that the Windows system forces you to accept shared memory to get concurrency, and those two are unrelated. The number of problems that want concurrency and memory protection is large, and eliminating that option is a MAJOR problem.
Having done a fair amount of GUI programming myself, I find a multiprocess solution is often correct (e.g. in something like Photoshop image filters, where you want shared access to one memory segment but don't need to share huge numbers of different memory segments where you can't easily compartmentalize them). For some jobs, though, multiple threads is better. Use the right tool for the job.
I didn't mean to say that there aren't some negative consequences to the choice of making threads performant and processes less so. There are, and your post correctly identifies one of them. But I think it's wrong to say that that design decision is therefore across-the-board wrong.
There are 2 seperate issues here 1. Are threads faster than process? Yes, on both Unix and Windows. 2. Are process so slow as to be essentially unusable for concurrency? On Windows, yes for a relatively large problem domain.
(2) is wrong. You force the programmer to give up memory protection in order to use an unrelated feature (concurrency).
There are times when a threaded architecture is appropriate, and that is harder to do in Unix (which is why Apache 1.x spawns processes, even though the 2.x codebase shows that threads are a better idea).
No, Apache used processes because they were a better idea. That's why most sites running 2.x on Unix continue to run it in multi-process mode even though multithreaded mode is available.
Not only does the multiprocess model avoid synchronization issues (see, e.g., http://www.zeuscat.com/andrew/work/aprbench/ for benchmarks showing that pre-fork is faster) but it avoids all the security/stability issues that come along with multithreading.
Would you rather have an obscure bug in some module you're using kill the current connection (and if it's repeatable, make that one page unloadable) or take down the whole web server? Do you want to limit the scope of security breaches?
Now, thread switches on their own are faster than process switches. With careful crafting you could design a threaded server that avoids synchronization issues and have it be faster than the multiproc version by that margin--but that's a very tiny margin that will likely be lost in the noise in any real-world server, and you're talking about increasing development cost dramatically for a return that's marginal at best. You'd be far better served putting that development effort into a state-machine based solution like thttpd or phhttpd if that level of performance is a concern.
That said, threads do have their place. Some problems are best solved with a shared-memory solution where the memory you need to share can't be easily isolated into a few SHM segments. And when that's the case, threads are the right tool for the job.
But the point is that if you don't have a reasonably performant process implementation then you remove the more commonly useful tool and force programmers to accept one feature (memory sharing) that could be very bad in order to use the one they really want (concurrency)--when those two features are really unrelated.
This problem isn't limited to Windows, either; Java similarly suffers from having no good way for programmers to use a multiprocess design.
It is, IMO, the single biggest technical problem with Windows.
Aren't there techniques for providing software memory protection? Software threading does have advantages.
The theoretical difference between threads and processes is essentially that threads share their memory while process do not*. So really using threads is exactly throwing out memory protection between the threads.
That's good and useful in some limited cases, but it's very bad in many cases. Unfortunately, a system without good process support requires you to choose "concurrent but no protection" or "no/crappy concurrency with protection".
IOW, by not having a good process implementation you force the programmer to accept an unrelated (and potentially very harmful) feature in order to use the feature they really want.
Not only that, but you make it impossible (or crappy) to use well-designed applications on your system. Witness Apache 1.x performance sucking rocks on Windows, and 2.x having a rewrite to use threads basically as a massive workaround for the crap performance of Windows processes--and that cascades down, even once Apache was modified many modules that (with good reason) relied on having seperate address spaces don't work in 2.x or need to be rewritten.
It's a massive problem. IMO, it's probably the single biggest technical problem with Windows (and Java too).
Think about this: suppose you have a helper process that your web server calls to go do something needing concurrency. And then a bug arises in that process. The results could be pretty bad, a remote overflow that can crash your machine or kill that helper. But you can limit the damage--the helper can run as a different user without access to the main httpd, limited fs permissions, etc.
Now put it into a thread instead of a process. Not only can it crash as before, but remote exploits could grovel around to find open database connections and wipe out data on the remote DB server. The web server could be brought down entirely. Etc. By losing compartementalization, you open a host of security issues.
And independent of security, a bug in that helper could wind up clobbering the DB or httpd accidentally (most likely a stray pointer access crashing the httpd and bringing down the whole site instead of just, say, the streaming videos or whatever the helper was used for).
*A few other resources may also be shared or not, depending on the system, but the core distiction is memory sharing.
Processes in Unix are lightweight objects, and the OS spawns them left and right. Processes in Windows are heavyweight objects, and the OS creates only a handfull of them. The lightweight objects in windows are threads, and you'll notice that Windows thread creation is faster than Unix thread creation. These are just different OS design philosophies.
No, they're not just different OS design philosophies. Windows forces you to choose between reasonably well-performing concurrency and memory protection. The poor performance of Windows processes is a root cause of many security holes and stability issues. OS designers spent years working on memory protection so that you could have reasonable isolation in the system and not have a bug in one area affect the whole system. When you're forced to use threads to get good concurrency, you effectively throw out a lot of that work and
Creating thousands of threads seems like a horribly inacurrate way to gauge performance. Creating a process is something that only goes on every once in a while -- threads or state machines are what are used when high levels of concurrency are required.
That's true on Windows but generally not on other platforms, and the only reason it's true on Windows is because of the horribly broken process implementation. Memory protection is a good thing, and there's no reason that you should throw it away because you need concurrency--Windows forces you to do that by using threads instead of processes, and the result is a host of security and stability issues.
Choosing threads vs. processes ought to be a decision over whether you want to share all your memory or not. In real OSes, that's the case. In Windows, it isn't--you have to choose the wrong tool for the job much of the time.
Basically, you're arguing that "Windows programmers use this horrible workaround that introduces lots of problems, but avoids this speed issue--so the speed issue is irrelevant."
In fact, this is highlighting that Windows' process performance is so horrible that programmers really are forced to use a miserable workaround that causes a lot of other problems.
Yawn, same old stuff - read the rest, Windows is better at thread switching. That makes up for the slow process creation. Windows programmers know that processs creation is slow, and thread creation is quick.
As a result, you get tons of unstable Windows applications because to get any reasonable concurrency you have to throw out the years of hard work that OS designers put into having protected memory.
Threads vs. processes isn't "two different ways of doing the same thing". Barring a massive implementation boondoggle, you make that choice based on whether you want memory protection or not. These numbers highlight a massive boondoggle, which takes the correct choice away from the application author in many cases.
Browsers could spend alot less effort kludging together DHTML and javascript and ride for free off of the JVM. I understand the JVM is a separate download, but browsers can include it as part of their install
As a user, I do have platforms that run firefox but for which there is no JVM port--getting JVM source is moderately painful and porting it is extremely painful. There are no good open-source JVMs out there, especially with full compatible browser implementations. So as a user, Java applications have more limited availability.
As a developer, I can count on Javascript and other AJAX technologies being a lot more prevalent than a JVM (even if one is available, the user may not have it installed and may decide it's not worthwile to do so for my application) so I get more potential users if I develop that way.
(Also as a developer I can use Python to develop the client-side code for either one and ignore legacy languages for the most part--though I need to be cognizant of their libraries. I could use Jython or py2js as appropriate)
Whatever happened to embedding python in firefox. That would be bitching: APAX
Existing APAX solutions use py2js so you write client code in python which is translated to javascript automagically.
See, e.g., Crackajax (or use plain py2js if you don't want a big framework).
what if I could write an Ajax application in Python? I set out to work, and came up with CrackAJAX, which uses the jsolait JavaScript library...It uses inspect.getsource(), mucks with the indentation a bit to make it parsable, and then parses it into ASTs. Then I plugged it into a modified version of a Python-to-JScript.NET compiler I wrote to do the translation.
Basically right unless you're willing to limit your client base to people with browsers that support other embedded languages (e.g Grail had embedded Python--but you couldn't do APAX with it as it lacked the AAX support).
But you can do your development in other languages and then convert to Javascript. I've known a few people who wrote simulated client-side Python and used py2js successfully. Still requires Javascript, but you can do your dev work in another language--using py2js requires that you limit what functions you use to a supported list, but some of that is "a simple matter of implementation" if the approach ever became popular.
so that optionaly, a web browser can inform the server that it has the option to connect to it using an open port on that system.
That would be nice but is unlikely to be a widespread solution. Huge numbers of ISPs do not allow incoming connections, many NAT boxes are outgoing only (there are some hacks to allow incoming connections but they aren't commonly implemented for corporate desktops), etc. IPv6 would be helpful in a move toward this kind of scenario..
But the best case right now is persistent connections via XMLHttpRequest and similar (as AJAX solutions use) where the browser initially connects but the connection is left open so that the server can notify the client of changes without the client polling intermittently. It requires that the server be able to deal with large numbers of open connections, which can be a bit of a downer.
Actually, there are Eastern Rite Catholics. Sort of between the Eastern Orthodox and Roman Catholics, and much fewer in number.
Just a couple more tidbits: 1. They are true Catholics, under the Pope in Rome. 2. They are the dominant but not only population accounting for the fact that about 20% of Catholic priests are married. But there are a few hundred legitimately married Catholic priests in the US (my priest growing up was a converted Episcopalian, a common way for this to happen--he was married with children). Spain ordained a married priest outright a couple months ago.
Slashdot Mirror
Gotcha. That makes sense.
Yet another reason to force all browser windows to have titlebars/buttons.
BTW *never* click on the corner X, that's not safe since a popup's corner X is sometimes a disguised "OK" button for installing something Nasty.
Windows really allows that? Ugh, that's nasty. Window managers should always be able to override applications.
I seem to remember that even though Google was much talked about in 2000, it had yet to become the preminent search engine it is today.
Remember that Google was the preeminent search engine (as far as effectiveness) for over a year before it left "beta" status--it had supplanted Altavista and Lycos well before then among the technically sophisticated. And then note that Google dropped the "beta" label in September of 1999. By then it was clearly the market leader technologically and possibly the leader by market share.
By June of 2000, Yahoo was using Google to do all their searches and it had clearly surpassed the alternatives by market share.
So why not add your name to the dictionary (You know, Right-click, add to dictionary)? Why should a general purpose word processor ship with every obscure last name installed by default in its dictionary?
The problem isn't that it's not in the dictionary. If I ran spell-check and my name was unrecognized, I'd have no problem with that. The problem is that if I typed my name, it would silently change it to the wrong thing--so even if I'm watching the screen, it's changing things several letters back without asking or notifying me.
I have no idea if autospell still works the same way, but at that time it truly just silently mangled things.
Aside from the value of getting publicity for security issues:
1999: Solitaire algorithm published. An output-feedback mode stream cipher which can be easily calculated using a pen, paper, and a deck of cards, allowing people without computers to use strong encryption in their communications. This system was featured in Neal Stephenson's Cryptonomicon.
2003: Helix algorithm published. A fast stream cipher comparable in speed to RC4 and with low per-message overhead, making it suitable for very small messages.
2004: Phelix algorithm published, a refinement of the earlier Helix algorithm.
Selection's a funny thing. You can have a ton, but unless you have what I'm looking for it's not worth much.
E.g. I just went and looked for a bunch of names (Living End, Richard Thompson, Tom Waits, PJ Harvey) and came up with a smattering of albums. The artist's most famous album was only available for Richard Thompson, and the rest of his more famous work was missing.
It's Fort Sumter, as others have noted.
But there was a famous Senator Charles Sumner from Boston, who gave an anti-slavery speech in 1956 and was promptly beaten senseless by South Carolina Senator Preston Brooks--he was knocked unconscious and then unable to attend Senate for 3 years. He became the leader of the Radical Republicans, arguing for black suffrage, extreme reconstruction acts, etc and leading the attempts to impeach Andrew Johnson.
OTOH, it is one of two major things that got me off Windows back in '94.
1. I can't type my name in MS Word ("Sumner") without it auto-"correcting" to "Summer". Sure, I can dig through menus and turn that off--but when you're in school using a different computer in the cluster every day that gets to be a pain in the ass.
2. At the time, all available winsock options froze hard if I tried to open 2 simultaneous network connections.
Glad to see that in the past decade they've fixed one of the 2.
Hey I'm just some novice who's ascended 5-10 times. I have a caveman right now who looks like he's going to make it too (past the quest, pretty complete ascension kit) if I don't do anything stupid. I'm trying to do one of each class (I have archaeologist, valkyrie, tourist, wizard, priest--some of those a couple times).
The 2 mantras you need to remember are:
1. Run away!
2. Don't take risks.
I played for like 10 years before ascending, but after the first time it gets a lot easier (like 1 month between 1st and 2nd time).
Also the early game has a lot more risk of death than the late game, so if you play carefully then you might die 20 times for every 1 character who gets past the Castle, but you'll ascend 90% of the ones who get that far (you can raise that percentage a lot if you're willing to be bored to tears, which I'm not).
But the real experts are guys like Marvin--he's playing in the online nethack tournament and ascended at least his first 9 consecutive characters without a death. And some of those guys do crazy conducts (e.g. playing a pacifist who never attacks anything, which usually means relying on pets to do all the killing).
The proper name for a text-mode program that works by moving the cursor around on a text screen and taking user input direct unbuffered keyboard input (ie., not making you hit ENTER after every command), is "Roguelike". Or at least that's what ESR calls them in his book.
Maybe ESR just made that term up recently
rec.games.roguelike (which includes r.g.r.nethack, r.g.r.moria, r.g.r.angband, etc) has been around since 1993 at least, and the term was used prior to that on Usenet back at least to 1989.
I prefer SLASH'EM myself, like Nethack but much, much worse.
SLASH'EM is generally regarded as significantly easier than Nethack once you learn how to play them both.
It's a lot harder when you're starting out (especially coming from a Nethack background, and learning that things like drain resistance are just as integral a part of a safe ascension kit as magic resistanc, reflection, etc), but once you've ascended a few times in each then slash'em has a lot more "outs".
Does Nethack qualify? Not quite text-only, but it will run on a terminal.
FYI.
The annual Nethack tournament is currently ongoing. Visit rec.games.roguelike.nethack for more info.
Highlights so far:
Marvin has ascended his first 9 consecutive characters (all from different classes).
Rast has an ascension in 10067 turns.
Most conducts for an ascension so far is 10 (illiterate weaponless atheist foodless polyless polyselfless wishless, which implies vegan vegetarian artifact-wishless).
In Unix/C you can install a signal handler to catch SIGSEGV. I don't do C++ so I don't know if there's an exception typically defined for that there.
As a result, you get tons of unstable Windows applications because to get any reasonable concurrency you have to throw out the years of hard work that OS designers put into having protected memory.
Throw out years of hard work? Give me a break! It almost seems that you are blaming the poor quality of modern threaded applications on Windows! That's rich!
No, I'm blaming Windows for the prevalence of multithreaded apps that don't need to be multithreaded. And yes, using threads throws out memory protection within the application; to an extent, it's like old unprotected Mac apps grovelling around in system memory. It requires a lot of discipline, and bugs are more able to bring the whole system down--and it's a lot less secure. That said, it's still sometimes the best option. But you shouldn't be forced into it.
Concurrency is difficult to use correctly no matter what technology you use.
Absolutely. Why compound that by throwing out shared memory as well?
Inter-process shared/mapped memory is just as susceptible to race conditions as cross-thread shared memory, and inter-process synchronization logic can deadlock just as easily as thread synchronization logic. And the results are the same: once a process is deadlocked, or corrupts its data due to a race condition, what difference does it make if it's running in its own address space? The software has failed catastrophically either way!
Example:
You have a helper function that does something asynchronously in your web server. Your helper segfaults when trying to read a file that's too large. Would you rather have the web server go down completely, or just have connections that try to load large files get closed?
In both cases the software has failed, but one is far more catastrophic. Obviously if you can write bug-free code then either way will work--one of the major reasons for having memory protection is that code is _not_ bug free, and when it fails you'd like to isolate the damage.
What's more, with an IPC solution you know explicitly what you're sharing; with a multithreaded solution it's a lot easier to not realize when another thread is accessing the same memory as you. It's a lot easier to introduce bugs that way, because you're sharing everything and not just the things you need to share.
Threads are certainly right for a lot of tasks, but that choice ought to be dictated by whether you need shared memory or not.
And it's not just a Windows problem. Java's worse in a lot of ways; at least, as you point out, there are ways to work around the problem in Windows. Java doesn't have any real multiprocess solution short of native extensions.
Threads certainly have a place, I never said otherwise. The problem is that the Windows system forces you to accept shared memory to get concurrency, and those two are unrelated. The number of problems that want concurrency and memory protection is large, and eliminating that option is a MAJOR problem.
Having done a fair amount of GUI programming myself, I find a multiprocess solution is often correct (e.g. in something like Photoshop image filters, where you want shared access to one memory segment but don't need to share huge numbers of different memory segments where you can't easily compartmentalize them). For some jobs, though, multiple threads is better. Use the right tool for the job.
I didn't mean to say that there aren't some negative consequences to the choice of making threads performant and processes less so. There are, and your post correctly identifies one of them. But I think it's wrong to say that that design decision is therefore across-the-board wrong.
There are 2 seperate issues here
1. Are threads faster than process? Yes, on both Unix and Windows.
2. Are process so slow as to be essentially unusable for concurrency? On Windows, yes for a relatively large problem domain.
(2) is wrong. You force the programmer to give up memory protection in order to use an unrelated feature (concurrency).
There are times when a threaded architecture is appropriate, and that is harder to do in Unix (which is why Apache 1.x spawns processes, even though the 2.x codebase shows that threads are a better idea).
No, Apache used processes because they were a better idea. That's why most sites running 2.x on Unix continue to run it in multi-process mode even though multithreaded mode is available.
Not only does the multiprocess model avoid synchronization issues (see, e.g., http://www.zeuscat.com/andrew/work/aprbench/ for benchmarks showing that pre-fork is faster) but it avoids all the security/stability issues that come along with multithreading.
Would you rather have an obscure bug in some module you're using kill the current connection (and if it's repeatable, make that one page unloadable) or take down the whole web server? Do you want to limit the scope of security breaches?
Now, thread switches on their own are faster than process switches. With careful crafting you could design a threaded server that avoids synchronization issues and have it be faster than the multiproc version by that margin--but that's a very tiny margin that will likely be lost in the noise in any real-world server, and you're talking about increasing development cost dramatically for a return that's marginal at best. You'd be far better served putting that development effort into a state-machine based solution like thttpd or phhttpd if that level of performance is a concern.
That said, threads do have their place. Some problems are best solved with a shared-memory solution where the memory you need to share can't be easily isolated into a few SHM segments. And when that's the case, threads are the right tool for the job.
But the point is that if you don't have a reasonably performant process implementation then you remove the more commonly useful tool and force programmers to accept one feature (memory sharing) that could be very bad in order to use the one they really want (concurrency)--when those two features are really unrelated.
This problem isn't limited to Windows, either; Java similarly suffers from having no good way for programmers to use a multiprocess design.
It is, IMO, the single biggest technical problem with Windows.
Aren't there techniques for providing software memory protection? Software threading does have advantages.
The theoretical difference between threads and processes is essentially that threads share their memory while process do not*. So really using threads is exactly throwing out memory protection between the threads.
That's good and useful in some limited cases, but it's very bad in many cases. Unfortunately, a system without good process support requires you to choose "concurrent but no protection" or "no/crappy concurrency with protection".
IOW, by not having a good process implementation you force the programmer to accept an unrelated (and potentially very harmful) feature in order to use the feature they really want.
Not only that, but you make it impossible (or crappy) to use well-designed applications on your system. Witness Apache 1.x performance sucking rocks on Windows, and 2.x having a rewrite to use threads basically as a massive workaround for the crap performance of Windows processes--and that cascades down, even once Apache was modified many modules that (with good reason) relied on having seperate address spaces don't work in 2.x or need to be rewritten.
It's a massive problem. IMO, it's probably the single biggest technical problem with Windows (and Java too).
Think about this: suppose you have a helper process that your web server calls to go do something needing concurrency. And then a bug arises in that process. The results could be pretty bad, a remote overflow that can crash your machine or kill that helper. But you can limit the damage--the helper can run as a different user without access to the main httpd, limited fs permissions, etc.
Now put it into a thread instead of a process. Not only can it crash as before, but remote exploits could grovel around to find open database connections and wipe out data on the remote DB server. The web server could be brought down entirely. Etc. By losing compartementalization, you open a host of security issues.
And independent of security, a bug in that helper could wind up clobbering the DB or httpd accidentally (most likely a stray pointer access crashing the httpd and bringing down the whole site instead of just, say, the streaming videos or whatever the helper was used for).
*A few other resources may also be shared or not, depending on the system, but the core distiction is memory sharing.
Processes in Unix are lightweight objects, and the OS spawns them left and right. Processes in Windows are heavyweight objects, and the OS creates only a handfull of them. The lightweight objects in windows are threads, and you'll notice that Windows thread creation is faster than Unix thread creation. These are just different OS design philosophies.
No, they're not just different OS design philosophies. Windows forces you to choose between reasonably well-performing concurrency and memory protection. The poor performance of Windows processes is a root cause of many security holes and stability issues. OS designers spent years working on memory protection so that you could have reasonable isolation in the system and not have a bug in one area affect the whole system. When you're forced to use threads to get good concurrency, you effectively throw out a lot of that work and
Creating thousands of threads seems like a horribly inacurrate way to gauge performance. Creating a process is something that only goes on every once in a while -- threads or state machines are what are used when high levels of concurrency are required.
That's true on Windows but generally not on other platforms, and the only reason it's true on Windows is because of the horribly broken process implementation. Memory protection is a good thing, and there's no reason that you should throw it away because you need concurrency--Windows forces you to do that by using threads instead of processes, and the result is a host of security and stability issues.
Choosing threads vs. processes ought to be a decision over whether you want to share all your memory or not. In real OSes, that's the case. In Windows, it isn't--you have to choose the wrong tool for the job much of the time.
Basically, you're arguing that "Windows programmers use this horrible workaround that introduces lots of problems, but avoids this speed issue--so the speed issue is irrelevant."
In fact, this is highlighting that Windows' process performance is so horrible that programmers really are forced to use a miserable workaround that causes a lot of other problems.
Yawn, same old stuff - read the rest, Windows is better at thread switching. That makes up for the slow process creation. Windows programmers know that processs creation is slow, and thread creation is quick.
As a result, you get tons of unstable Windows applications because to get any reasonable concurrency you have to throw out the years of hard work that OS designers put into having protected memory.
Threads vs. processes isn't "two different ways of doing the same thing". Barring a massive implementation boondoggle, you make that choice based on whether you want memory protection or not. These numbers highlight a massive boondoggle, which takes the correct choice away from the application author in many cases.
Browsers could spend alot less effort kludging together DHTML and javascript and ride for free off of the JVM. I understand the JVM is a separate download, but browsers can include it as part of their install
As a user, I do have platforms that run firefox but for which there is no JVM port--getting JVM source is moderately painful and porting it is extremely painful. There are no good open-source JVMs out there, especially with full compatible browser implementations. So as a user, Java applications have more limited availability.
As a developer, I can count on Javascript and other AJAX technologies being a lot more prevalent than a JVM (even if one is available, the user may not have it installed and may decide it's not worthwile to do so for my application) so I get more potential users if I develop that way.
(Also as a developer I can use Python to develop the client-side code for either one and ignore legacy languages for the most part--though I need to be cognizant of their libraries. I could use Jython or py2js as appropriate)
Existing APAX solutions use py2js so you write client code in python which is translated to javascript automagically.
See, e.g., Crackajax (or use plain py2js if you don't want a big framework).
http://www.aminus.org/blogs/index.php/phunt/2005/
I think TurboGears has something similar.
Asynchronous And XML?
With out Javascript AJAX doesn't work.
Basically right unless you're willing to limit your client base to people with browsers that support other embedded languages (e.g Grail had embedded Python--but you couldn't do APAX with it as it lacked the AAX support).
But you can do your development in other languages and then convert to Javascript. I've known a few people who wrote simulated client-side Python and used py2js successfully. Still requires Javascript, but you can do your dev work in another language--using py2js requires that you limit what functions you use to a supported list, but some of that is "a simple matter of implementation" if the approach ever became popular.
so that optionaly, a web browser can inform the server that it has the option to connect to it using an open port on that system.
That would be nice but is unlikely to be a widespread solution. Huge numbers of ISPs do not allow incoming connections, many NAT boxes are outgoing only (there are some hacks to allow incoming connections but they aren't commonly implemented for corporate desktops), etc. IPv6 would be helpful in a move toward this kind of scenario..
But the best case right now is persistent connections via XMLHttpRequest and similar (as AJAX solutions use) where the browser initially connects but the connection is left open so that the server can notify the client of changes without the client polling intermittently. It requires that the server be able to deal with large numbers of open connections, which can be a bit of a downer.
Actually, there are Eastern Rite Catholics. Sort of between the Eastern Orthodox and Roman Catholics, and much fewer in number.
Just a couple more tidbits:
1. They are true Catholics, under the Pope in Rome.
2. They are the dominant but not only population accounting for the fact that about 20% of Catholic priests are married. But there are a few hundred legitimately married Catholic priests in the US (my priest growing up was a converted Episcopalian, a common way for this to happen--he was married with children). Spain ordained a married priest outright a couple months ago.