> Very simply, without idle bottom halves, there's no way to implement > polling with the main loop. If we dropped idle bottom halves, we would > have to add explicit polling back to the main loop. > > How would you implement polling?
AFAICS any sort of polling is by definition time based so use a timer. Forcing the user to explicitly decide how often to poll is a feature. If they don't know this then they probably shouldn't be using polling. > > I don't see how this helps. A self-triggering event with a timeout of > > "now" is still an infinite loop. Any delay is a bugs in the dispatch > > loop. "idle" BHs are relying on this bug. > > The main point is that BHs should not be implemented in the actual main > loop and that "idle" BHs are really the only type of BHs that should > exist as far as the main loop is concerned. s/"idle" BHs/idle > callbacks/g and I think we're at a more agreeable place. Part of my difficulty is that I don't have a clear idea what "idle" means. It certainly isn't what qemu_bh_schedule_idle implements. The only vaguely sane definition I can come up with is once the main loop has run out of useful things to do and is about to suspend itself. Typically no significant guest code will be executed between requesting the idle callback and the callback occurring. In an SMP host environment it may be possible for guest CPUs to trigger or observe intermediate events, but this can not be relied upon. Given this definition I'm unclear how useful this would be. A BH is a deferred callback that is used to allow events to be processed. IMO the important feature is that it is a deferred until after the current event has been processed, so avoid a whole set of reentrancy problems. Of course if you misuse them you can cause infinite loops, in the same way that misusing a regular callback will lead to infinite recursion. I'm not sure that replacing BHs with zero interval timers actually gains us anything. From a user(device) perspective I'd be more inclined to make timers trigger a BH when they expire, like the ptimer code. Idle events can then be handled in exactly the same way: the user provides a BH which is triggered the next time the idle event occurs. The exact source of a call to a BH routine from is an implementation detail. The important thing is that they will never be invoked from within or concurrent with any other device callback. Paul
