Another one of my original points (which I think among others was lost) was that NT had IOCP in 1995. According to a manpage and a quick google search, epoll() did not come about until 2002.
2001 actually.
As "all Unix programmers" will know (your term), poll() is a much less scalable interface, for reasons that do not apply to IOCP.
epoll (it's not a function) is a scalable implementation of interface with poll() semantics. It was added after scalability of the rest of the system caused poll() to become a bottleneck in a specific application of a single server thread with very large number of simultaneously connected clients. The history of this is recorded in http://www.kegel.com/c10k.html
Please note, at which number of concurrent connections the scalability problem manifested itself in the first place.
I'm still kind of skeptical that you know what the NT interfaces look like because in practice they are *extremely similar* to uses of epoll() and kqueue() [and not just in my programs]. A lot of writing out there about IOCP focuses unnecessarily on concurrency but if the last parameter to CreateIoCompletionPort is 1 and keep it on a single thread it's pretty similar to the Unix approach. And it existed years earlier.
No, then you still can't combine simultaneous waiting on unlimited number of I/O operations, you are forced to use concurrency for that. Unix design is very strict when it comes to concurrency in I/O model -- if user does not specifically want it, system does not impose it.
And on Unix you can delegate I/O to a thread/process, while keeping interactions to that process nonblocking, thanks to vastly superior IPC. For the tiny number of situations where such nonblocking mechanism is necessary (all GUI-related, and all only affect superficial "snappiness" of interface), this is a perfectly acceptable solution.
You claimed that poll tells you the exact number of bytes that are ready, which is false
I said no such thing.
poll() tells you that you can perform an I/O operation of a certain kind, and it is not expected to fail. Details of I/O operation (or results of additional I/O that kernel may perform between poll() and read()/write()/...) are only visible after the userspace performs data transfer. Kernel then copies only the amount of userspace-supplied data that it can transfer, so the procedure is very efficient.
My point is, poll() only returns when there is I/O to perform, so it does not cause busy loops or fruitless context switches (when the process wakes up only to find that it has nothing to do). Successful completion of a write operation is not a good reason to wake up userspace -- it adds nothing useful to the I/O state (once buffer is sent to the kernel, kernel either sends it, or "dies trying" when the connection is dropped with a separate error condition) and complicates the semantics of kernel I/O operations (when do we REALLY know that the I/O completed successfully? When ACK is received on a TCP socket? When DMA completed on the last byte sent over the serial port? No, that breaks streaming, caching and pretty much everything done by modern hardware).
1. It was not Yangtze river itself. 2. None of the chemicals mentioned are bright red. 3. The amount of red subtance that requires such color change over the whole river likely exceeds the capacity of any chemical production in the whole China. Yellow color was caused by clay, so there is no reason to suspect anything other than clay unless demonstrated otherwise. 4. Water pollutants are water-soluble, red substance that is seen in the river now is clearly suspension.
When I lived in Russia two decades ago, I knew that Apple HQ is somewhere between San Francisco and San Jose, but didn't know in what city. I didn't know where Sunnyvale is until I have moved to San Mateo, and Sunnyvale had the best computer/electronics store in the area (Fry's on Lawrence Expressway).
For a minute there I thought you were talking about Fox News.
That would be: "Take all my taxes, draft people, raid Rupert Murdoch's home with a bunch of helicopters, and I don't mind if you kill him in the process!"
...that river was called golden for a reason -- it always carries suspended particles of clay, so the color of the river depends on the composition of clay around it.
Red clay is nothing unusual, so most likely the river eroded some part of a bank with a different clay composition. If this is the case, any sane geologist should be able to find the place along the river where color changes, take water samples, and determine the source.
All code is "not testable" as far as all aspects of its behavior are concerned. Tests never guarantee anything other than two pieces of code, code under test and the test itself, happen to have bugs that are complementary under one given condition.
Not only I write code for living, I do so for two decades, and never seen a Visual Studio user who used it for any reaon other than compensating for his stupidity or ignorance.
You do realize people write free software to solve their own problems right?
And those are not the people who write GNOME 3. GNOME 3 developers write free software to feel important and powerful, just like all other pretentious assholes.
American spaceship, Russian spaceship: all fixed with toothbrush!
As far as I know, Salyut and Mir didn't have screws hammered into threads at an angle. Bottles of vodka smuggled inside spacesuits on Progress, botched docking while "experimenting" with manual controls for no earthly (or space-y) reason -- sure. Stripped threads on the outside structures -- no.
Slashdot Mirror
moar liek /g/ is slashdot, retard edition.
...was gained.
(kidding)
2001 actually.
Well, actual implementation was released in 2002.
Another one of my original points (which I think among others was lost) was that NT had IOCP in 1995. According to a manpage and a quick google search, epoll() did not come about until 2002.
2001 actually.
As "all Unix programmers" will know (your term), poll() is a much less scalable interface, for reasons that do not apply to IOCP.
epoll (it's not a function) is a scalable implementation of interface with poll() semantics. It was added after scalability of the rest of the system caused poll() to become a bottleneck in a specific application of a single server thread with very large number of simultaneously connected clients. The history of this is recorded in http://www.kegel.com/c10k.html
Please note, at which number of concurrent connections the scalability problem manifested itself in the first place.
I'm still kind of skeptical that you know what the NT interfaces look like because in practice they are *extremely similar* to uses of epoll() and kqueue() [and not just in my programs]. A lot of writing out there about IOCP focuses unnecessarily on concurrency but if the last parameter to CreateIoCompletionPort is 1 and keep it on a single thread it's pretty similar to the Unix approach. And it existed years earlier.
No, then you still can't combine simultaneous waiting on unlimited number of I/O operations, you are forced to use concurrency for that. Unix design is very strict when it comes to concurrency in I/O model -- if user does not specifically want it, system does not impose it.
And on Unix you can delegate I/O to a thread/process, while keeping interactions to that process nonblocking, thanks to vastly superior IPC. For the tiny number of situations where such nonblocking mechanism is necessary (all GUI-related, and all only affect superficial "snappiness" of interface), this is a perfectly acceptable solution.
You claimed that poll tells you the exact number of bytes that are ready, which is false
I said no such thing.
poll() tells you that you can perform an I/O operation of a certain kind, and it is not expected to fail. Details of I/O operation (or results of additional I/O that kernel may perform between poll() and read()/write()/...) are only visible after the userspace performs data transfer. Kernel then copies only the amount of userspace-supplied data that it can transfer, so the procedure is very efficient.
My point is, poll() only returns when there is I/O to perform, so it does not cause busy loops or fruitless context switches (when the process wakes up only to find that it has nothing to do). Successful completion of a write operation is not a good reason to wake up userspace -- it adds nothing useful to the I/O state (once buffer is sent to the kernel, kernel either sends it, or "dies trying" when the connection is dropped with a separate error condition) and complicates the semantics of kernel I/O operations (when do we REALLY know that the I/O completed successfully? When ACK is received on a TCP socket? When DMA completed on the last byte sent over the serial port? No, that breaks streaming, caching and pretty much everything done by modern hardware).
1. It was not Yangtze river itself.
2. None of the chemicals mentioned are bright red.
3. The amount of red subtance that requires such color change over the whole river likely exceeds the capacity of any chemical production in the whole China. Yellow color was caused by clay, so there is no reason to suspect anything other than clay unless demonstrated otherwise.
4. Water pollutants are water-soluble, red substance that is seen in the river now is clearly suspension.
When I lived in Russia two decades ago, I knew that Apple HQ is somewhere between San Francisco and San Jose, but didn't know in what city.
I didn't know where Sunnyvale is until I have moved to San Mateo, and Sunnyvale had the best computer/electronics store in the area (Fry's on Lawrence Expressway).
Fine. That explains California. Now what about the rest of the country?
Military-industrial complex and financial companies, the greatest parasites ever.
For a minute there I thought you were talking about Fox News.
That would be:
"Take all my taxes, draft people, raid Rupert Murdoch's home with a bunch of helicopters, and I don't mind if you kill him in the process!"
You think, tapeworms will make better decisions than those asshats?
...that river was called golden for a reason -- it always carries suspended particles of clay, so the color of the river depends on the composition of clay around it.
Red clay is nothing unusual, so most likely the river eroded some part of a bank with a different clay composition. If this is the case, any sane geologist should be able to find the place along the river where color changes, take water samples, and determine the source.
All code is "not testable" as far as all aspects of its behavior are concerned. Tests never guarantee anything other than two pieces of code, code under test and the test itself, happen to have bugs that are complementary under one given condition.
Not only I write code for living, I do so for two decades, and never seen a Visual Studio user who used it for any reaon other than compensating for his stupidity or ignorance.
You do realize people write free software to solve their own problems right?
And those are not the people who write GNOME 3. GNOME 3 developers write free software to feel important and powerful, just like all other pretentious assholes.
Shut up, hairyfeet!
Congratulations, you are an idiot!
Xfce breaks viewport switching when I use Compiz, KDE does not.
Has working applets and does not occasionally decide to resize itself to the size of the largest icon in some menu or applet.
Because it does not work!
It imitates the look of the default Gnome 2 setup, but so does a wallpper of a screenshot.
Forgot to kick your wife again, Chuck?
100% of their old customers
All five of them!
American spaceship, Russian spaceship: all fixed with toothbrush!
As far as I know, Salyut and Mir didn't have screws hammered into threads at an angle. Bottles of vodka smuggled inside spacesuits on Progress, botched docking while "experimenting" with manual controls for no earthly (or space-y) reason -- sure. Stripped threads on the outside structures -- no.
Only if you are one of those retards who single-step through their programs in futile attempts to understand what the fuck they wrote.
I don't know, SCO was kinda slow to die, Nokia has a good chance to show a better time.