Are you familiar with Windows Structured Exception Handling (SEH)? While I have learned some about signals in an educational context, I have nowhere near the experience with error handling on Unix as I do on Windows (and thus don't know if Unix has anything similar to SEH). SEH is, more or less literally, C++ exceptions that are thrown for things like access violations (the kind of stuff that would generate serious signals). You can catch these exceptions in catch blocks in the thread that caused the violation (or rethrow it if you can't deal with it, and let a higher up handler catch it; stack classes can also be destructed as an exception gets propogated upward), and actually recover from the error. This method is quite slow (can take hundreds of thousands of cycles for a catch block to get executed after an exception is thrown), but that's incomparably superior to having the thread (or the process) die due to some access violation. I should also add that the overhead of SEH blocks (when exceptions are not thrown) is very low - only 1-2 dozen cycles per function that has a catch block. This is a far more elegant solution to exception handling than anything I know of on Unix (but again, I could be unaware of something on Unix).
From what I can gather from Linux Kernel 2.4 Internals, Linux gives elevated priority to threads that haven't run in a while, while NT uses thread priorities literally (a semi-cooperative multitasking system; information taken from Inside Windows NT). However, NT will temporarily boost thread priority for threads waiting on something (in this case I would imagine the desktop would be waiting on the message queue), so it should still give the desktop elevated priority (priority above what the ZIP program would have) and thus a fair chance at the CPU.
It's possible the ZIP program you're using is badly behaved and setting itself to high priority (lots of programs like that have options to set the priority of their worker threads; if yours has one, setting the priority to low will be certain to fix your problem); that would explain the observed slowdown, as NT would give significantly more CPU time to the ZIP program (you'll have to investigate that for yourself, as I've never had that problem, nor do I know exactly what program you're using).
It's also possible that you have your Windows configured to give priority to background tasks (this is a setting you can modify) rather than foreground apps (Windows usually gives a priority boost to whatever application is the foreground app). This could also explain your experience, as again the CPU would be going primarily to the ZIP program running in the background.
Singularity can only get you so far. I expect Singularity to work well for preventing application crashes, and it should significantly speed up interprocess communication. It may even somewhat reduce the amount of blue-screens (or whatever color the Linux equivalent is); but it won't be able to help with most kernel mode faults, because it still can't protect the software from the hardware. The hardware is still free to stomp all over program, driver, and OS memory, because a driver made some error in sending values to the hardware (which is impossible for the JITer to validate).
Systems like that are usually fairly stable, but quite slow, as the overhead of interprocess communication is high. If the information I've received is accurate (I don't have any first-hand knowledge on the matter) OS X is structured kinda like that, and that's part of the reason it's sluggish (at least it some aspects). Singularity takes a radically different (and perhaps misguided) approach to stability.
I've made a couple of posts on my blog listing the technical pros and cons of Singularity as a real-life OS (the latter I just wrote and put up today).
My experience is much like the other respondants' with respect to crashes. While it always hurts to lose a page or more of a term paper, Word and Excel (Office XP edition) crash only two or three times a year, for me (combined). Heck, I used to lose 1.44" floppies more often than that:P
Also, I've never used OpenOffice, so I can't compare it to MS Office, but I've always found MS Office to be very compact (i.e. Word only takes 16 megs RAM with my completed finance term paper open).
NT, in particular, at that point, was a bad joke of a server operating system.
Why is that, exactly (and no, I'm not looking for Slashdot Windows-is-the-biggest-piece-of-crap-in-the-histor y-of-computers tag-lines, I'm looking for actual information)?
You do have to write a different version of your app for every version of Windows. OK, maybe it's not 6, but there are massive differences between Windows 98 and, say, Windows 2000. Windows XP represents another, albeit less disruptive, set of changes. Windows Vista will probably represent the biggest set of changes yet. Each of these is a development target, with its own QA requirements and so on.
Okay, let me go over this point by point:
1. There are certainly significant differences between NT and 9x, but with the exception of bugs, later versions of NT or 9x (staying inside the series) are a functional superset of previous versions. If you write a version for 95, it'll work on all later versions of 9x; a program written for NT 3.1 will work on all later versions of NT.
2. The differences between NT and 9x are irrelivant from the article writer's point of view, because at the time he's talking about (NT 3.1) 9x didn't exist (at least, it wouldn't be released for 2 more years).
3. Windows Vista will be not unlike a new line of Windows (compared to 3.1, NT, 9x) and so will likely have significant differences.
Windows 9x is a strange creature. It's probably the single largest blemish on Win32's record (9x is primarily the one responsible for the every-man-an-admin problem, as well as various others, such as the belief that Windows crashes every three seconds), but it's entirely possible that without 9x Win32 wouldn't have caught on (think about it: XP is really the first version of NT that's widely used on home computers).
Utter nonsense. Do you use Azureus? Perhaps you've played WURM Online? Do you need to clean up your hard drive?
The Java is slow myth is a load of hogwash that opponents of the technology use to justify their stance against it. It's simply not true, and hasn't been true for a very long time. And if you don't believe me, talk to NASA.
In fact I do use Azureus regularly (it's my primary BitTorrent client). But in all seriousness, it's horribly slow (enough to literally make your reference to it laughable). Try benchmarking creation of a torrent, and compare it to a native implimentation of the hash algorithm (SHA-1, I think it was). It's mind-bogglingly slow. Not only that, but it's mind-bogglingly bloated. It's not unusual for it to take 60-80 megs when I'm downloading one torrent (and runs some 3 threads or so per connected peer). A friend (who downloads way more stuff on BT than I do) says it's not unusual for Azureus to take hundreds of megs of RAM on his computer.
As for myself, I did some benchmarking of my own. When.NET first came out, I assumed it (specifically the JITed MSIL) would be slow, probably as slow as Java (although at the time I didn't have a clear idea of how fast Java was; just that it was "slow" - i.e. the stereotype). So I did some benchmarks. Compared to a native implementation of ZLib in C, the same code compiled to MSIL (managed C++) was 2/3 as fast (that is, it took 1.5x as long to compress the same data). The Java version (this was an actual Java port of the ZLib source, not the built-in, native implementation in the Java runtime), on the other hand, was half as fast (2x as long to compress). This actually raised my opinion of.NET, as it proved a fair bit faster than my expectations (while Java was also faster than my expectations, it fell unambiguously below.NET in terms of speed).
Excuse my ignorance, but WTF does 'free as in beer' mean, and how does that differ from 'free as in speech'? I've never seen those used anywhere but here, and all my friends (90+% of them being programmers, technicians, and administrators, some even visiting/. regularly) haven't the slightest clue what that means.
You, uh, do know that in order get the levees fit to stand up to Katrina, upgrading work would have needed to be started before Bush even took office, right? I'm not saying Bush did the right thing in cutting the budget, I'm just saying that his cutting the budget had no effect on this disaster.
The buzz with end users this week is that Open Source Development Labs (OSDL) chose wisely when it rejected an allegedly independent comparison of Linux and Windows.
Unless there was a second page in that (Linux web site hosted) article that I missed, that is the ONLY time end users are ever mentioned, and the rest of the article is quotes from several Linux technicians/developers, one independant developer, and a very brief appearance by an MS person. Where the heck did all these end users come from? Unless I'm missing something huge (like that aforementioned second page), this article is no better supported by evidence than MS' anti-Linux press releases.
You must like to argue. Either that or you must like to post redundant stuff. In any case, it's distressing that there are so many people who think you said something good. I mention this because what you said is exactly what the article says. Thanks for wasting a comment, and wasting several people's mod points.
I can only think you're referring to Win16 DLLs. In Win32, all processes have isolated address spaces, and DLLs are confined to the address space of the process that loads the DLL. While you can mark some variables of a DLL as shared (so that all copies of the DLL will share them, across processes), this is of very limited use, as only the variables themselves will be shared, and not any allocated resources. If you want to share resources, you have to go through the kernel, creating file sections (for sharing memory), duplicating handles (for sharing kernel resources), etc.; these are exactly the same procedures you'd go through to have an EXE share resources with another EXE. And even when the DLL allocates resources, the resources are owned by the process, not the DLL. There isn't anything special about DLLs, save for the ability to link to them at run time (and even that isn't unique to DLLs - you can have a DLL dynamically link to the EXE, as well).
The only time where you'd have memory allocated by a DLL that couldn't be freed by the EXE (or vice versa) is when the DLL statically links to the CRT. In this case the CRT would maintain its own private list of free blocks, which the EXE wouldn't know where to find. This is a problem with the CRT, however, and not Windows: memory allocated through the Windows API is always owned by the process; and this problem dissappears if both EXE and DLL are dynamically linked to the CRT (so that there's only one list of free blocks).
DLLs are not just shared libraries, but blend in aspects of process memory that raises hell with shared memory management, especially if a process dies without properly releasing it's resources. A DLL can own resources, while a shared library is only for sharing code and static data. It's far cleaner and safer to have some sort of actual manager process create and manage shared memory and similar resources than it is to put that functionality into a quasi-process like a DLL.
Quasi-process? Shared memory management, with respect to a process crashing? I've been using DLLs for years, and I have no clue what you're talking about. Well, I take that back. It sounds like you could be talking about DLLs in Win16 (which is older than my experience with coding, but I have read some about them), as DLLs in Win32 bear near 0% resemblance to what you've just described. To briefly summarize the differences between what you've described and real DLLs (that is, the only ones that you'll ever need to write code for: Win32 DLLs):
- DLLs are not processes, quasi-processes, or anything even remotely resembling processes. DLLs are loaded and run in the process that loaded them. All their allocated resources, handles, etc., are owned by that process, not the DLL. If the process crashes, all that gets released on process destruction, just like resources the EXE itself allocated.
- DLLs are almost never used to share memory between processes. You can mark certain data segments as shared to accomplish this, but I'd consider that more of a hack than a useful feature of DLLs. Shared memory will almost always be implemented cleanly, by means of a "manager" (as you call it), such as the NT kernel (i.e. file mappings) or COM (remote procedure calls and marshalling).
- DLLs have next to no resemblance to TSRs whatsoever (yes, I've read about TSRs, too), for reasons including the ones I've already mentioned.
And lastly, yes, there are many things that are unpleasant to do with COM. Just ask a C programmer to write you an ActiveX control, and watch them start bawling. Alternately, ask anybody (other than a VB programmer) to add on a dispatch interface to their COM object, and watch them scream, turn white, and pass out.
How exactly do you define 'hack', in this case? Are you just defining that as anything that's a copy of something else? I mean really, the Unix way of versioning shared libraries strikes me as being a hack. And by that, I mean something that was tacked on as an unplanned, emergency last-minute addition when it was discovered that such a thing was needed.
Mod parent up. I certainly don't like it (in fact, I downright hate it), but this is how more businesses than not work. If you want to get their products for anything other than retail, you'll probably have to sign some kind of "good faith" contract.
I'd be ecstatic if this was done away with, but until that happens (which will probably be never), you can't say MS is any worse than average.
On the other hand, selects are definitely more compact in memory. Of course Windows has WaitForMultipleObjects() for the same purposes as select() (and if it's just sockets you're waiting on, you can use good old select() instead)
...no. Neither WaitForMultipleObjects nor Windows' select compares to Unix select (both are significantly less efficient, and I might add that both are limited to 64 files/sockets). On the other hand, NT I/O completion ports wipe the floor with Unix's select.
In Unix, fork()ing is very efficient. It's just as fast or faster than creating a thread in Windows. The reason is that both processes use the same set of pages in memory - until one writes to memory, and then one gets a copy.
Yes, forking is considerably faster than creating a process from scratch like NT does (as I noted), and copy on write dampens the memory comsumption by preventing things that the child process doesn't use from being physically duplicated (which makes the memory efficiency of Unix processes nearly as good as NT processes, which carry over nothing whatsoever from the parent process).
But you seem to have the grossly mistaken notion that copy on write (which is used all over NT, BTW) is a magic bullet. Forking still doesn't come close to the speed of creating a thread on NT (nor on Unix, for that matter; even if a Unix OS implements threads as processes with a shared environment, it will be significantly faster than setting up the page tables and other things). Just because unused pages are shared between two processes (via copy on write) doesn't remove the overhead of the separate virtual address spaces themselves (page directories, etc., which I referred to). Besides that, you ARE creating a separate running process; The memory of the new process will quickly get populated will its own data, causing there to be (surprise!) twice as much physical data as before the fork (assuming the two programs are the same, so they have the same memory requirements).
Now, allow me to provide THE final word of the difference between a thread and a process:
Process
An address space with one or more threads executing within that address space, and the required system resources for those threads.
Thread
A single flow of control within a process. Each thread has its own thread ID, scheduling priority and policy, errno value, thread-specific key/value bindings, and the required system resources to support a flow of control. Anything whose address may be determined by a thread, including but not limited to static variables, storage obtained via malloc(), directly addressable storage obtained through implementation-defined functions, and automatic variables, are accessible to all threads in the same process.
Those would be quotes from The Open Group Base Specifications Issue 6, Definitions.
How does that apply to this discussion? It tells us that you're confusing the specification with the implementation. NT can also create processes that share address spaces, but you can't do so with any API available to programmers (did you know that NT can fork, too? but you also can't do that with any API available to programmers); this is no different than Linux and other flavors of Unix. A process by definition has a separate address space, while threads of the same process by definition share an address space. In other words, even on Unix, processes (if they do any IPC) will be MUCH slower than threads running in the same process (for further details of why this is, see my longer post from earlier).
Slashdot Mirror
Are you familiar with Windows Structured Exception Handling (SEH)? While I have learned some about signals in an educational context, I have nowhere near the experience with error handling on Unix as I do on Windows (and thus don't know if Unix has anything similar to SEH). SEH is, more or less literally, C++ exceptions that are thrown for things like access violations (the kind of stuff that would generate serious signals). You can catch these exceptions in catch blocks in the thread that caused the violation (or rethrow it if you can't deal with it, and let a higher up handler catch it; stack classes can also be destructed as an exception gets propogated upward), and actually recover from the error. This method is quite slow (can take hundreds of thousands of cycles for a catch block to get executed after an exception is thrown), but that's incomparably superior to having the thread (or the process) die due to some access violation. I should also add that the overhead of SEH blocks (when exceptions are not thrown) is very low - only 1-2 dozen cycles per function that has a catch block. This is a far more elegant solution to exception handling than anything I know of on Unix (but again, I could be unaware of something on Unix).
From what I can gather from Linux Kernel 2.4 Internals, Linux gives elevated priority to threads that haven't run in a while, while NT uses thread priorities literally (a semi-cooperative multitasking system; information taken from Inside Windows NT). However, NT will temporarily boost thread priority for threads waiting on something (in this case I would imagine the desktop would be waiting on the message queue), so it should still give the desktop elevated priority (priority above what the ZIP program would have) and thus a fair chance at the CPU.
It's possible the ZIP program you're using is badly behaved and setting itself to high priority (lots of programs like that have options to set the priority of their worker threads; if yours has one, setting the priority to low will be certain to fix your problem); that would explain the observed slowdown, as NT would give significantly more CPU time to the ZIP program (you'll have to investigate that for yourself, as I've never had that problem, nor do I know exactly what program you're using).
It's also possible that you have your Windows configured to give priority to background tasks (this is a setting you can modify) rather than foreground apps (Windows usually gives a priority boost to whatever application is the foreground app). This could also explain your experience, as again the CPU would be going primarily to the ZIP program running in the background.
Singularity can only get you so far. I expect Singularity to work well for preventing application crashes, and it should significantly speed up interprocess communication. It may even somewhat reduce the amount of blue-screens (or whatever color the Linux equivalent is); but it won't be able to help with most kernel mode faults, because it still can't protect the software from the hardware. The hardware is still free to stomp all over program, driver, and OS memory, because a driver made some error in sending values to the hardware (which is impossible for the JITer to validate).
A more in-depth version of this post
Oops. There was a mistake in the hyperlink in that post (making it not show up). Should have been 'misguided'
Systems like that are usually fairly stable, but quite slow, as the overhead of interprocess communication is high. If the information I've received is accurate (I don't have any first-hand knowledge on the matter) OS X is structured kinda like that, and that's part of the reason it's sluggish (at least it some aspects). Singularity takes a radically different (and perhaps misguided) approach to stability.
I've made a couple of posts on my blog listing the technical pros and cons of Singularity as a real-life OS (the latter I just wrote and put up today).
Agreed. Would be highly amusing to watch quantum physics be disproved. But I definitely won't believe it till I see it.
Indeed. I once submitted a story that was rejected, and it later got posted by somebody else... three times
My experience is much like the other respondants' with respect to crashes. While it always hurts to lose a page or more of a term paper, Word and Excel (Office XP edition) crash only two or three times a year, for me (combined). Heck, I used to lose 1.44" floppies more often than that :P
Also, I've never used OpenOffice, so I can't compare it to MS Office, but I've always found MS Office to be very compact (i.e. Word only takes 16 megs RAM with my completed finance term paper open).
NT, in particular, at that point, was a bad joke of a server operating system.
r y-of-computers tag-lines, I'm looking for actual information)?
Why is that, exactly (and no, I'm not looking for Slashdot Windows-is-the-biggest-piece-of-crap-in-the-histo
You do have to write a different version of your app for every version of Windows. OK, maybe it's not 6, but there are massive differences between Windows 98 and, say, Windows 2000. Windows XP represents another, albeit less disruptive, set of changes. Windows Vista will probably represent the biggest set of changes yet. Each of these is a development target, with its own QA requirements and so on.
Okay, let me go over this point by point:
1. There are certainly significant differences between NT and 9x, but with the exception of bugs, later versions of NT or 9x (staying inside the series) are a functional superset of previous versions. If you write a version for 95, it'll work on all later versions of 9x; a program written for NT 3.1 will work on all later versions of NT.
2. The differences between NT and 9x are irrelivant from the article writer's point of view, because at the time he's talking about (NT 3.1) 9x didn't exist (at least, it wouldn't be released for 2 more years).
3. Windows Vista will be not unlike a new line of Windows (compared to 3.1, NT, 9x) and so will likely have significant differences.
Windows 9x is a strange creature. It's probably the single largest blemish on Win32's record (9x is primarily the one responsible for the every-man-an-admin problem, as well as various others, such as the belief that Windows crashes every three seconds), but it's entirely possible that without 9x Win32 wouldn't have caught on (think about it: XP is really the first version of NT that's widely used on home computers).
Utter nonsense. Do you use Azureus? Perhaps you've played WURM Online? Do you need to clean up your hard drive?
.NET first came out, I assumed it (specifically the JITed MSIL) would be slow, probably as slow as Java (although at the time I didn't have a clear idea of how fast Java was; just that it was "slow" - i.e. the stereotype). So I did some benchmarks. Compared to a native implementation of ZLib in C, the same code compiled to MSIL (managed C++) was 2/3 as fast (that is, it took 1.5x as long to compress the same data). The Java version (this was an actual Java port of the ZLib source, not the built-in, native implementation in the Java runtime), on the other hand, was half as fast (2x as long to compress). This actually raised my opinion of .NET, as it proved a fair bit faster than my expectations (while Java was also faster than my expectations, it fell unambiguously below .NET in terms of speed).
The Java is slow myth is a load of hogwash that opponents of the technology use to justify their stance against it. It's simply not true, and hasn't been true for a very long time. And if you don't believe me, talk to NASA.
In fact I do use Azureus regularly (it's my primary BitTorrent client). But in all seriousness, it's horribly slow (enough to literally make your reference to it laughable). Try benchmarking creation of a torrent, and compare it to a native implimentation of the hash algorithm (SHA-1, I think it was). It's mind-bogglingly slow. Not only that, but it's mind-bogglingly bloated. It's not unusual for it to take 60-80 megs when I'm downloading one torrent (and runs some 3 threads or so per connected peer). A friend (who downloads way more stuff on BT than I do) says it's not unusual for Azureus to take hundreds of megs of RAM on his computer.
As for myself, I did some benchmarking of my own. When
Excuse my ignorance, but WTF does 'free as in beer' mean, and how does that differ from 'free as in speech'? I've never seen those used anywhere but here, and all my friends (90+% of them being programmers, technicians, and administrators, some even visiting /. regularly) haven't the slightest clue what that means.
You, uh, do know that in order get the levees fit to stand up to Katrina, upgrading work would have needed to be started before Bush even took office, right? I'm not saying Bush did the right thing in cutting the budget, I'm just saying that his cutting the budget had no effect on this disaster.
The buzz with end users this week is that Open Source Development Labs (OSDL) chose wisely when it rejected an allegedly independent comparison of Linux and Windows. Unless there was a second page in that (Linux web site hosted) article that I missed, that is the ONLY time end users are ever mentioned, and the rest of the article is quotes from several Linux technicians/developers, one independant developer, and a very brief appearance by an MS person. Where the heck did all these end users come from? Unless I'm missing something huge (like that aforementioned second page), this article is no better supported by evidence than MS' anti-Linux press releases.
You must like to argue. Either that or you must like to post redundant stuff. In any case, it's distressing that there are so many people who think you said something good. I mention this because what you said is exactly what the article says. Thanks for wasting a comment, and wasting several people's mod points.
...a female on Slashdot? If I believed that, that would be the scariest thing I've heard in years.
I can only think you're referring to Win16 DLLs. In Win32, all processes have isolated address spaces, and DLLs are confined to the address space of the process that loads the DLL. While you can mark some variables of a DLL as shared (so that all copies of the DLL will share them, across processes), this is of very limited use, as only the variables themselves will be shared, and not any allocated resources. If you want to share resources, you have to go through the kernel, creating file sections (for sharing memory), duplicating handles (for sharing kernel resources), etc.; these are exactly the same procedures you'd go through to have an EXE share resources with another EXE. And even when the DLL allocates resources, the resources are owned by the process, not the DLL. There isn't anything special about DLLs, save for the ability to link to them at run time (and even that isn't unique to DLLs - you can have a DLL dynamically link to the EXE, as well).
The only time where you'd have memory allocated by a DLL that couldn't be freed by the EXE (or vice versa) is when the DLL statically links to the CRT. In this case the CRT would maintain its own private list of free blocks, which the EXE wouldn't know where to find. This is a problem with the CRT, however, and not Windows: memory allocated through the Windows API is always owned by the process; and this problem dissappears if both EXE and DLL are dynamically linked to the CRT (so that there's only one list of free blocks).
DLLs are not just shared libraries, but blend in aspects of process memory that raises hell with shared memory management, especially if a process dies without properly releasing it's resources. A DLL can own resources, while a shared library is only for sharing code and static data. It's far cleaner and safer to have some sort of actual manager process create and manage shared memory and similar resources than it is to put that functionality into a quasi-process like a DLL.
Quasi-process? Shared memory management, with respect to a process crashing? I've been using DLLs for years, and I have no clue what you're talking about. Well, I take that back. It sounds like you could be talking about DLLs in Win16 (which is older than my experience with coding, but I have read some about them), as DLLs in Win32 bear near 0% resemblance to what you've just described. To briefly summarize the differences between what you've described and real DLLs (that is, the only ones that you'll ever need to write code for: Win32 DLLs):
- DLLs are not processes, quasi-processes, or anything even remotely resembling processes. DLLs are loaded and run in the process that loaded them. All their allocated resources, handles, etc., are owned by that process, not the DLL. If the process crashes, all that gets released on process destruction, just like resources the EXE itself allocated.
- DLLs are almost never used to share memory between processes. You can mark certain data segments as shared to accomplish this, but I'd consider that more of a hack than a useful feature of DLLs. Shared memory will almost always be implemented cleanly, by means of a "manager" (as you call it), such as the NT kernel (i.e. file mappings) or COM (remote procedure calls and marshalling).
- DLLs have next to no resemblance to TSRs whatsoever (yes, I've read about TSRs, too), for reasons including the ones I've already mentioned.
And lastly, yes, there are many things that are unpleasant to do with COM. Just ask a C programmer to write you an ActiveX control, and watch them start bawling. Alternately, ask anybody (other than a VB programmer) to add on a dispatch interface to their COM object, and watch them scream, turn white, and pass out.
COM is a watered-down hack of CORBA
How exactly do you define 'hack', in this case? Are you just defining that as anything that's a copy of something else? I mean really, the Unix way of versioning shared libraries strikes me as being a hack. And by that, I mean something that was tacked on as an unplanned, emergency last-minute addition when it was discovered that such a thing was needed.
Mod parent up. I certainly don't like it (in fact, I downright hate it), but this is how more businesses than not work. If you want to get their products for anything other than retail, you'll probably have to sign some kind of "good faith" contract.
I'd be ecstatic if this was done away with, but until that happens (which will probably be never), you can't say MS is any worse than average.
Weird hack? Can you explain to me... 1) How COM and DLLs are a hack? 2) How the Unix way is so decisively superior to COM and DLLs?
On the other hand, selects are definitely more compact in memory. Of course Windows has WaitForMultipleObjects() for the same purposes as select() (and if it's just sockets you're waiting on, you can use good old select() instead)
...no. Neither WaitForMultipleObjects nor Windows' select compares to Unix select (both are significantly less efficient, and I might add that both are limited to 64 files/sockets). On the other hand, NT I/O completion ports wipe the floor with Unix's select.
In Unix, fork()ing is very efficient. It's just as fast or faster than creating a thread in Windows. The reason is that both processes use the same set of pages in memory - until one writes to memory, and then one gets a copy.
Yes, forking is considerably faster than creating a process from scratch like NT does (as I noted), and copy on write dampens the memory comsumption by preventing things that the child process doesn't use from being physically duplicated (which makes the memory efficiency of Unix processes nearly as good as NT processes, which carry over nothing whatsoever from the parent process).
But you seem to have the grossly mistaken notion that copy on write (which is used all over NT, BTW) is a magic bullet. Forking still doesn't come close to the speed of creating a thread on NT (nor on Unix, for that matter; even if a Unix OS implements threads as processes with a shared environment, it will be significantly faster than setting up the page tables and other things). Just because unused pages are shared between two processes (via copy on write) doesn't remove the overhead of the separate virtual address spaces themselves (page directories, etc., which I referred to). Besides that, you ARE creating a separate running process; The memory of the new process will quickly get populated will its own data, causing there to be (surprise!) twice as much physical data as before the fork (assuming the two programs are the same, so they have the same memory requirements).
*actual
Now, allow me to provide THE final word of the difference between a thread and a process:
Process
An address space with one or more threads executing within that address space, and the required system resources for those threads.
Thread
A single flow of control within a process. Each thread has its own thread ID, scheduling priority and policy, errno value, thread-specific key/value bindings, and the required system resources to support a flow of control. Anything whose address may be determined by a thread, including but not limited to static variables, storage obtained via malloc(), directly addressable storage obtained through implementation-defined functions, and automatic variables, are accessible to all threads in the same process.
Those would be quotes from The Open Group Base Specifications Issue 6, Definitions.
How does that apply to this discussion? It tells us that you're confusing the specification with the implementation. NT can also create processes that share address spaces, but you can't do so with any API available to programmers (did you know that NT can fork, too? but you also can't do that with any API available to programmers); this is no different than Linux and other flavors of Unix. A process by definition has a separate address space, while threads of the same process by definition share an address space. In other words, even on Unix, processes (if they do any IPC) will be MUCH slower than threads running in the same process (for further details of why this is, see my longer post from earlier).