On Thu, Jun 26, 2008 at 01:42, André Braga <meianoite@xxxxxxxxx> wrote: > Be itself didn't implement this strategy > because it was not necessary on BeOS, which related priorities to > processing roles in a well-defined manner. BTW, those priorities as defined by Be don't work too well when using a fair scheduler. Consider: B_NORMAL_PRIORITY 10 B_DISPLAY_PRIORITY 15 B_URGENT_DISPLAY_PRIORITY 20 A fair, priority-based scheduler would schedule a thread with B_NORMAL_PRIORITY half as many times as another thread with B_URGENT_DISPLAY_PRIORITY, because the ratios among their numeric priorities is 1:2. We know pretty well that those are *not* the semantics we desire when we spawn threads using those priorities. So our options are to go the Linux route and base the fairness on CPU usage (and there are signs that this _doesn't_work_well_); try and manage to implement branding (a.k.a. subsystem-based priority inheritance) in order to boost threads that are supposed to be very responsive; or give up on the goal of having a fair scheduler and go back to using a static, sorted-by-priority-based scheduler like the one in BeOS. Aye. A.