Last time I have seen such a package for Windows, it had some toy scanning software and "photo management" utility. It also crapped out when I have upgraded MSIE because it used it internally. Really, a half-assed piece of crap.
Actually, he is right -- Windows developers are infected with thinking centered around Microsoft design. When they write software for other systems, they try to follow Microsoft-ish style, not realizing that they are dealing with a far more advanced and at the same time far more simple system. The results are terrible, and Linux users are better off without this kind of sabotage.
It is the first time ever that Intel announced direct hostility toward some piece of software -- I hope, it's just someone's fuckup and not a policy change.
Arguments/data in select() and poll() (and epoll in most its uses) have identical semantics, only different layout of data structures, so methods were the same for the whole time, interface varied, imposing its own limitations. Most free software could be built for select() or poll() depending on the OS it was built for, and programmers did not see it as a significant problem to support both.
Unix at the time had select() which limits you to a small number of descriptors.
select() implementations usualy limited the number of file descriptors to 1024 (not 256 like many believe), and theoretically it was possible to keep using select() data layout for unlimited number of file descriptors by allowing arrays of fd_set. poll() merely happened to provide a cleaner interface for the programmer, so it was adopted as a more convenient solution.
As usual, people who had a choice, adopted poll() precisely at the point when it made sense (1997 for Linux, 1998 in FreeBSD), much later than commercial Unix transition to SysV that forced poll() into those systems before there was a technical justification (1986 for System V itself, early 90's for commercial Unix systems).
WaitForMultipleObjects serves as the same (the handle limit is lower but determining what's signalled is O(1)).
It's not O(1) until process and I/O schedulers, and I/O routines are O(1) -- in reality it's very close to O(n) for n being the amount of I/O (duh -- someone has to perform it) and very far from O(n) with n being the number of channels/fd like you are implying (except on Windows in the given timeframe, where it was probably much worse than all of those, and Windows now when it's likely still bad compared to Unix). The time used to scan the list of file descriptors in system call interface (on both kernel and userspace sides) is very small compared to the actual operations performed, this is why scalability is only a problem for very sparse I/O on a very large number of connections. Far, far greater performance limitations are imposed by dealing with the same sparse I/O inside the kernel, especially network stack and buffering.
I was talking about the early history of NT, which existed only internally for quite a few years and I've heard folklore from people that know. Before they added the Win32 subsystem.
There is plenty of folklore glorifying the early Windows NT design, however from what is known now it seems like there was much more of the Windows-ish design in the core than claimed. Win32 is ugly, but its ugliness came from the same people and design philosophy.
Either way, omitting blocking I/O would be a stupid idea, especially in OS where process/threads concurrency is used and overused everywhere. I can believe that Microsofties would see it as "cool" and "revolutionary", but only because I have very low opinion on their software design abilities in the first place.
First and foremost, the drought and starvation happened in both Ukraine and Russia, so any source that claims any exclusivity for Ukraine is most likely bullshit. Second, OVERPRODUCE??? Are you fucking nuts??? Advanced agricultural techniques were not invented yet, no one had any control over agricultural productivity, least of all government -- whatever could be grown, was harvested, everything else was up to nature. Drought over the whole grain-producing region meant massive shortages of grain. Third, if any of those "estimates" were true, there would be no people in Ukraine left. And I would not be born. And you would be arguing with a ghost. Boo!
So who, do you think, really won election in Russia? The choices, other than United Russia, were:
1. Communists (KPRF -- YA, RLY, second largest number of seats in the parliament). 2. Clowns with disturbingly fascist tendencies (LDPR). 3. Socialists (Just Russia). 4. US-worshipping Libertarians (Yabloko).
That was the whole point of the NT effort, to create a clean break.
And instead of providing better interface to the well-known, well-developed, proven to be effective I/O model, they have chosen the wrong I/O model. Typical Microsoft.
My understanding of the history is that synchronous I/O was added somewhat late in development as an afterthought.
That would not be possible, considering that they had to replicate the functionality of all DOS system calls, even including bizarre CP/M stuff like FindFirstFile()/FindNextFile().
What is epoll_wait then, if not a means to drain the contents of a kernel queue from user space?
No, it exposes exactly the same thing as poll() -- list of file descriptors that can be read, written, or with particular conditions happened on them. Kernel may not even have access to the data that arrived at that point (unlikely in general, as kernel usually is "greedy" when it comes to buffering, but perfectly possible for devices with DMA or fast FIFOs, or complex network stacks), leave alone having it queued.
In particular, on some FPGA-based systems it's possible to have FIFOs that are as fast or faster than CPU cache. Once such FIFO signalled to have data, it's safer to wait for userspace to tell kernel where to copy that data, rather than try to copy it immediately (so as much as possible of that data will go from FIFO to cache and stay there for processing before there will be a chance that it will be evicted from that cache). This means, kernel will have no way to know how much data is available until userspace tried to read it (!).
Might as well put that in your user buffer while you're at it.
No. Kernel does all kinds of things that involve buffering -- interrupts handling, DMA, passing around socket buffers, etc. None of this was ever intended to be visible from userspace because all those things are device-specific and implementation-specific. Not in interface but in semantics of events and data within the kernel. This is where "no stable ABI" that Windows fans whine about, is so important -- so kernel can implement anything in the most efficient and scalable manner. Exposing any of that to userspace would be pure madness. The fact that read()/recv()/... produces serialized data but kernel is free to keep things in any format internally, keeps userspace from messing with device specifics and details of protocols.
It's a very important design choice -- when device performs unsolicited operation on known I/O primitive (represented by existing file descriptor of any nature), kernel can respond regardless of the userspace having or not having requested any I/O, and userspace can pick up the results after being told by kernel. Windows requires both I/O primitive and operation in progress, even though operation may never succeed and its userspace buffer will be wasted.
Maybe I'll grant you that the Windows way encourages more allocations, especially if applied naively.
And it requires more allocation even if applied in any other manner -- you either have to use inefficient I/O operation, or you have to use completion ports and request all possible I/O operations to have them pending at the same time. Either was scalability is down the toilet.
But if you have content to read and write you're going to need allocations anyway,
But you don't! Most connections most of the time are idle -- if this was not the case, it would be a trivial case when scalability is limited by hardware throughput, and OS does not matter. When all sockets are passing data all the time, polling in a busy loop will be sufficient, and all exercises in scalability would be pointless.
and as you pointed out the kernel will already be doing them "unsolicited", so you might as well tell it where to put it.
Kernel does it internally, using data structures and hardware buffers that have no place in userspace.
Famous examples of this include the forced collectivization of farms in the Ukraine between 1928 and 1933,
Only if you take works of American anti-USSR propaganda as fact. It was a massive drought, coinciding with inexperienced government trying to prevent even more disastrous starvation, all the while being in the middle of of economic reform that laid foundation for recovery.
Yes, because in addition to passing a large pollfd array at each syscall, after poll() returns you have to do an O(N) pass through the pollfds to find the one that's signalled.
And until a truly giant numbers of descriptors was involved, it did not matter because the scanning operation itself takes insignificant time -- O(N) of nothing is still nothing. The total size of the data being passed back and forth between userspace and kernel is a greater problem than that.
GetQueuedCompletionStatus(), implemented 1995, unlike poll(), does not pass a large amount of data around in its syscall and does not require an O(N) pass to determine what's signalled.
Oh please, don't tell me that Windows NT could even serve thousands of active connections in 1995 without choking up. Before the number of file descriptors served by a single process reached thousands, any such "improvements" were solving a nonexistent problem, and this is why poll() was perfectly appropriate for Unix.
Again, that's not true! You can put arbitrary amounts of I/O on a single completion port and drain that single completion queue on a single thread.
I mean, waiting for all possible conditions on all file descriptors -- arrival of data or new connection being most important of them. poll()/epoll allows the userspace program to wait for I/O conditions such as data arrival, connections established, etc., and only after such condition is detected call the I/O operation that handles it. This is scalable and fits the nonblocking I/O model from userspace point of view -- no userspace-visible queue is involved at any point, no I/O operations in progress from userspace point of view even if kernel is performing unsolicited I/O internally due to the nature of device or socket. Windows insists that you have to wait for operations in progress -- allocate thousands of distinct buffers, start thousands of operations, then wait on all of them.
Slashdot Mirror
Last time I have seen such a package for Windows, it had some toy scanning software and "photo management" utility. It also crapped out when I have upgraded MSIE because it used it internally. Really, a half-assed piece of crap.
The "info" is "just use it on Windows 8 with our great modified kernel".
Visual Studio
Please, please, please, stay on Windows, we don't need your Microsoft-infected minds spreading their diseases to other systems.
Actually, he is right -- Windows developers are infected with thinking centered around Microsoft design. When they write software for other systems, they try to follow Microsoft-ish style, not realizing that they are dealing with a far more advanced and at the same time far more simple system. The results are terrible, and Linux users are better off without this kind of sabotage.
Until few days ago, Intel never ever claimed that their CPUs are for Windows and only Windows.
Oh wow, hairyfeet and his Microsoft marketing again.
No, it's the case of kill all your friends, then yourself.
What? Angry Birds runs on N900 just fine.
Shooting the messenger is the quickest way to lose an argument.
Shooting THIS kind of messenger keeps Microsoft from shitting up the conversation.
If you don't like what they are doing, don't buy their product.
Only if you are Libertarian or at least Republican -- they believe that people have no right to defend themselves from "the market".
I hear AMD makes some fine chips.
This is completely irrelevant, and AMD does not make low-power x86 chips anymore.
It is the first time ever that Intel announced direct hostility toward some piece of software -- I hope, it's just someone's fuckup and not a policy change.
Shut up, Microsoft astroturfer!
We will complain about whatever we want to complain, companies should serve their customers and not the other way around.
I hope Intel that releases the source of the crack that they are smoking.
They license it from Microsoft.
queue in epoll is an interface. It does not expose kernel internals where completely different queues serve different purposes.
Your favored methods were not in use at the time.
Arguments/data in select() and poll() (and epoll in most its uses) have identical semantics, only different layout of data structures, so methods were the same for the whole time, interface varied, imposing its own limitations. Most free software could be built for select() or poll() depending on the OS it was built for, and programmers did not see it as a significant problem to support both.
Unix at the time had select() which limits you to a small number of descriptors.
select() implementations usualy limited the number of file descriptors to 1024 (not 256 like many believe), and theoretically it was possible to keep using select() data layout for unlimited number of file descriptors by allowing arrays of fd_set. poll() merely happened to provide a cleaner interface for the programmer, so it was adopted as a more convenient solution.
As usual, people who had a choice, adopted poll() precisely at the point when it made sense (1997 for Linux, 1998 in FreeBSD), much later than commercial Unix transition to SysV that forced poll() into those systems before there was a technical justification (1986 for System V itself, early 90's for commercial Unix systems).
WaitForMultipleObjects serves as the same (the handle limit is lower but determining what's signalled is O(1)).
It's not O(1) until process and I/O schedulers, and I/O routines are O(1) -- in reality it's very close to O(n) for n being the amount of I/O (duh -- someone has to perform it) and very far from O(n) with n being the number of channels/fd like you are implying (except on Windows in the given timeframe, where it was probably much worse than all of those, and Windows now when it's likely still bad compared to Unix). The time used to scan the list of file descriptors in system call interface (on both kernel and userspace sides) is very small compared to the actual operations performed, this is why scalability is only a problem for very sparse I/O on a very large number of connections. Far, far greater performance limitations are imposed by dealing with the same sparse I/O inside the kernel, especially network stack and buffering.
I was talking about the early history of NT, which existed only internally for quite a few years and I've heard folklore from people that know. Before they added the Win32 subsystem.
There is plenty of folklore glorifying the early Windows NT design, however from what is known now it seems like there was much more of the Windows-ish design in the core than claimed. Win32 is ugly, but its ugliness came from the same people and design philosophy.
Either way, omitting blocking I/O would be a stupid idea, especially in OS where process/threads concurrency is used and overused everywhere. I can believe that Microsofties would see it as "cool" and "revolutionary", but only because I have very low opinion on their software design abilities in the first place.
Oh yeah, right, GNOME3 crap makes people switch to Windows. Are you a moron?
Kill all your friends, then yourself.
ABI
Another Microsoft marketing guy.
Michael Meeks (michael.meeks@novell.com)
Figures...
No.
First and foremost, the drought and starvation happened in both Ukraine and Russia, so any source that claims any exclusivity for Ukraine is most likely bullshit.
Second, OVERPRODUCE??? Are you fucking nuts??? Advanced agricultural techniques were not invented yet, no one had any control over agricultural productivity, least of all government -- whatever could be grown, was harvested, everything else was up to nature. Drought over the whole grain-producing region meant massive shortages of grain.
Third, if any of those "estimates" were true, there would be no people in Ukraine left. And I would not be born. And you would be arguing with a ghost. Boo!
election rigging
So who, do you think, really won election in Russia? The choices, other than United Russia, were:
1. Communists (KPRF -- YA, RLY, second largest number of seats in the parliament).
2. Clowns with disturbingly fascist tendencies (LDPR).
3. Socialists (Just Russia).
4. US-worshipping Libertarians (Yabloko).
That was the whole point of the NT effort, to create a clean break.
And instead of providing better interface to the well-known, well-developed, proven to be effective I/O model, they have chosen the wrong I/O model. Typical Microsoft.
My understanding of the history is that synchronous I/O was added somewhat late in development as an afterthought.
That would not be possible, considering that they had to replicate the functionality of all DOS system calls, even including bizarre CP/M stuff like FindFirstFile()/FindNextFile().
What is epoll_wait then, if not a means to drain the contents of a kernel queue from user space?
No, it exposes exactly the same thing as poll() -- list of file descriptors that can be read, written, or with particular conditions happened on them. Kernel may not even have access to the data that arrived at that point (unlikely in general, as kernel usually is "greedy" when it comes to buffering, but perfectly possible for devices with DMA or fast FIFOs, or complex network stacks), leave alone having it queued.
In particular, on some FPGA-based systems it's possible to have FIFOs that are as fast or faster than CPU cache. Once such FIFO signalled to have data, it's safer to wait for userspace to tell kernel where to copy that data, rather than try to copy it immediately (so as much as possible of that data will go from FIFO to cache and stay there for processing before there will be a chance that it will be evicted from that cache). This means, kernel will have no way to know how much data is available until userspace tried to read it (!).
Might as well put that in your user buffer while you're at it.
No. Kernel does all kinds of things that involve buffering -- interrupts handling, DMA, passing around socket buffers, etc. None of this was ever intended to be visible from userspace because all those things are device-specific and implementation-specific. Not in interface but in semantics of events and data within the kernel. This is where "no stable ABI" that Windows fans whine about, is so important -- so kernel can implement anything in the most efficient and scalable manner. Exposing any of that to userspace would be pure madness. The fact that read()/recv()/... produces serialized data but kernel is free to keep things in any format internally, keeps userspace from messing with device specifics and details of protocols.
It's a very important design choice -- when device performs unsolicited operation on known I/O primitive (represented by existing file descriptor of any nature), kernel can respond regardless of the userspace having or not having requested any I/O, and userspace can pick up the results after being told by kernel. Windows requires both I/O primitive and operation in progress, even though operation may never succeed and its userspace buffer will be wasted.
Maybe I'll grant you that the Windows way encourages more allocations, especially if applied naively.
And it requires more allocation even if applied in any other manner -- you either have to use inefficient I/O operation, or you have to use completion ports and request all possible I/O operations to have them pending at the same time. Either was scalability is down the toilet.
But if you have content to read and write you're going to need allocations anyway,
But you don't! Most connections most of the time are idle -- if this was not the case, it would be a trivial case when scalability is limited by hardware throughput, and OS does not matter. When all sockets are passing data all the time, polling in a busy loop will be sufficient, and all exercises in scalability would be pointless.
and as you pointed out the kernel will already be doing them "unsolicited", so you might as well tell it where to put it.
Kernel does it internally, using data structures and hardware buffers that have no place in userspace.
I could've just asked CIA to "predict" where they are going to attack.
Famous examples of this include the forced collectivization of farms in the Ukraine between 1928 and 1933,
Only if you take works of American anti-USSR propaganda as fact. It was a massive drought, coinciding with inexperienced government trying to prevent even more disastrous starvation, all the while being in the middle of of economic reform that laid foundation for recovery.
starvation is nothing more than a natural lust for profit.
Sorry to add reality to your bashing the rich.
THIS IS WHAT SOCIAL CONSERVATIVES REALLY BELIEVE.
Yes, because in addition to passing a large pollfd array at each syscall, after poll() returns you have to do an O(N) pass through the pollfds to find the one that's signalled.
And until a truly giant numbers of descriptors was involved, it did not matter because the scanning operation itself takes insignificant time -- O(N) of nothing is still nothing. The total size of the data being passed back and forth between userspace and kernel is a greater problem than that.
GetQueuedCompletionStatus(), implemented 1995, unlike poll(), does not pass a large amount of data around in its syscall and does not require an O(N) pass to determine what's signalled.
Oh please, don't tell me that Windows NT could even serve thousands of active connections in 1995 without choking up. Before the number of file descriptors served by a single process reached thousands, any such "improvements" were solving a nonexistent problem, and this is why poll() was perfectly appropriate for Unix.
Again, that's not true! You can put arbitrary amounts of I/O on a single completion port and drain that single completion queue on a single thread.
I mean, waiting for all possible conditions on all file descriptors -- arrival of data or new connection being most important of them. poll()/epoll allows the userspace program to wait for I/O conditions such as data arrival, connections established, etc., and only after such condition is detected call the I/O operation that handles it. This is scalable and fits the nonblocking I/O model from userspace point of view -- no userspace-visible queue is involved at any point, no I/O operations in progress from userspace point of view even if kernel is performing unsolicited I/O internally due to the nature of device or socket. Windows insists that you have to wait for operations in progress -- allocate thousands of distinct buffers, start thousands of operations, then wait on all of them.
Without water they wouldn't have gelsacs!
Or Zalgo. Or reversed names.