> that is one of the near-insoluble problems of select/poll. The > go-ahead is decoupled from what you want to do, and can be out of > sync. (Which is what started this whole discussion.) That lie > is the unforgivable sin of polling
Well yes, if poll() keeps lying about event availability, then your program will loop a few times without doing any progress. But that is not a problem in poll's design, it's a problem in the implementation. Lying about event availability is not supposed to happen often. According to Rich, it is not even supposed to happen at all. > and when it's coupled with the > fact that with poll/select you only have one timeout, which you have > to manipulate depending on what is going on _everywhere_ else in > the program That is no difficulty at all. Compute a deadline for every event in your program (unlike timeouts, deadlines do not change at every loop invocation); the difference between now and the earliest deadline is your main timeout. If poll() times out, you know that the event that timed out was the one with the earliest deadline. Problem solved. For people who are unable to do the minor computations involved, the Linux guys went as far as providing them with as many individual timers as they want: timerfd(). This is really encouraging excessive laziness. > you start to wonder why you're using that kind of a poor > tool to begin with. My pursuance of event-driven AIO is just sugar > on top of NOT using polling in general, and poll/select in specific. > I am biased, but I believe I have good reason to be. Well, you do not like the select/poll API, and it's your right, and everyone agrees that API is far from perfect. But you just can't justify your dislike by pretending that it's not an event-driven paradigm API, because it is. One of your points is that poll() is easy to misuse, and a badly written program will use poll() as a polling tool at different times in the code, instead of organizing every event neatly around a single poll() point as is necessary in an event-driven program. It is true, the poll() API does not compel you to write clean programs, and the DNIX completion queues are probably more foolproof. The fact that completion queues can themselves be used recursively in asynchronous events is very neat, and the system must be quite robust indeed; nevertheless, a well-written poll() program is just as robust - it's just harder to write. My point is that what you want can already be achieved using what we have. I am not denying that more comfortable, easier to use, more foolproof APIs exist to achieve the same thing; and would completion queues make it into Single Unix, I would probably switch to them and be very happy with it. But the tools we have *can* already be used in a clean way, so I don't see the need for an urgent fix, whereas some other things (such as a per-fd nonblocking flag) do need one. > that era) did not. (In single-CPU systems, which most DNIX boxes > were, LWP's are just a way to reorganize the problem and offer no > inherent performance or maintainability advantage over an AIO > approach, and might actually be a performance liability.) Threads are also purely a question of taste. Rich likes them. Lots of people like them. I don't. Alan Cox doesn't. YMMV. > They do; if the app is structured to do this only in one place it's > nearly the same thing structure-wise. The presence of poll semantics > seems to encourage NOT doing this in only one place, in which case > the potential problems multiply with the quantity of poll/select calls. poll() didn't start the fire, you know. Give your average computer programmer an API, *any* API, and you'll be amazed at the incredible creativity that people have to misuse said API and write terrible code that manages to almost work and break in subtle ways you would never have imagined. I bet your dear foolproof completion queues can also be misused in horrible ways, too. But I'm not going to start a contest. ;) -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
