>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.
I maintain that it _is_ a problem with poll's design, because poll doesn't/can't know enough about what you wish to do in the future to be 100% reliable, and CANNOT know about external factors that destroy the orderly behavior you're counting on. "It's more of a guideline, really..." These disruptive external factors (shared fd's) will or will not damage what you're doing depending on the nature of the communication on these fd's, but will almost certainly damage poll/select's ability to maintain program responsiveness. Unless you've managed to actually change all fd's in the system to be non-blocking, and changed all I/O routines to handle early returns, etc. That's my point. Because poll/select is such a poor tool you have to change everything else in the system to accommodate it. With a better tool, you don't. >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 That's what I'm talking about, you have to subsume into your main loop all the tiny details of all your program's logic. Can be done, most of the time perhaps, but unpleasant. >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. That's actually a step in the right direction, too bad it's Linux-only. Is certainly easy to abuse, I've seen it here. Just because you _can_ have your own timer per-whatever, doesn't mean you _should_! It's a balancing act. At least such abuse is usually only a performance problem, and can be cured without affecting anything else by rewriting that bit of the application. >But you just can't justify >your dislike by pretending that it's not an event-driven paradigm API, >because it is. It _is_ an event-driven paradigm, yes. But a poor version! That's what I dislike. >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. No, it's not urgent. It's a shame though, to me, that here we are 20+ years later and still band-aiding the same poor tool that was first conceived at Berkeley in (I guess) CS101. The same guys that invented file descriptors that weren't file descriptors (sockets) brought you polling as the main paralleling API. This crap's hanging on longer than DOS did! If people were accustomed to using a good, long-standing AIO scheme then we wouldn't NEED a per-fd nonblocking flag, etc. I submit that the whole mess would have stabilized years ago, with no continuing need to tinker with the guts of the mechanism. >Threads are also purely a question of taste. Rich likes them. Lots >of people like them. I don't. Alan Cox doesn't. YMMV. I'm torn. Sometimes good, sometimes bad. We're actually having very good luck using them in our product at work, but that's because it was a port from an OS whose processes were more like threads. (Shared memory space.) Also, our main synchronization mechanism is message-passing (via Linx), which is quite clean. We've had few problems with this, but that's mostly because the gross bugs were already shaken out years ago in the original OS. Starting from scratch I would _not_ have used threads. Or very few threads at least, rather than the 100+ that's in it now. The most evil fallout from threads was the necessity to eliminate all forks in our program. 99% of the time it worked just fine, but every once in awhile it crashed. We wasted man-months chasing that, it was some kind of conflict with glibc fork vs malloc. Ugh. So I had to invent a fork server (the Blue Rajah: Master of Cutlery, Forks a Specialty :-), and get rid of all system/fork/popen calls. What a nightmare, there's still a bit of fallout from that two years later. >I bet your dear foolproof completion queues can also be misused in >horrible ways, too. But I'm not going to start a contest. ;) Not foolproof, but somewhat harder to misuse IMHO. How does that famous phrase go? "Never underestimate the stupidity of the computing public?" Or something like that... -- Jim _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox