On 02/23/2010 08:58 PM, Paul Brook wrote:
Bottom halves are run at the very end of the event loop which means that
they're guaranteed to be the last thing run. idle bottom halves can be
rescheduled without causing an infinite loop and do not affect the
select timeout (which normal bottom halves do).
Idle bottom halves (i.e. qemu_bh_schedule_idle) are just bugs waiting to
happen, and should never be used for anything.
Idle bottom halves make considerable more sense than the normal bottom
halves.
The fact that rescheduling a bottom half within a bottom half results in
an infinite loop is absurd. It is equally absurd that bottoms halves
alter the select timeout. The result of that is that if a bottom half
schedules another bottom half, and that bottom half schedules the
previous, you get a tight infinite loop. Since bottom halves are used
often times deep within functions, the result is very subtle infinite
loops (that we've absolutely encountered in the past).
A main loop should have only a few characteristics. It should enable
timeouts (based on select), it should enable fd event dispatch, and it
should allow for idle functions to be registered. There should be no
guarantees on when idle functions are executed other than they'll
eventually be executed.
The way we use "bottom halves" today should be implemented in terms of a
relative timeout of 0 or an absolute timeout of now. The fact that we
can't do that in our main loop is due to the very strange dependencies
deep within various devices on io dispatch ordering. I would love to
eliminate this but I've not been able to spend any time on this recently.
Regards,
Anthony Liguori
Paul