[OT] poll() vs. AIO (was: [PATCH] ash: clear NONBLOCK flag from stdin when in foreground)

Cathey, Jim jcathey at ciena.com
Fri Aug 19 17:03:40 UTC 2011


>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






More information about the busybox mailing list