Our thread priorities on Mozilla are all normal. We are not upping thr priorities at all.
Mikus Grinbergs wrote: > Had an audio stream (started as a Mozilla helper application) > playing in the background, while I did a little web surfing. > Did not measure how much load that audio stream put on my system, > but I'm convinced it was *substantially* less than 50% of the > system's processing capacity. > > Now, several times while Mozilla was rendering webpages that > had a lot on them, the audio stream "dropped out". [Looked to > me like lack of processing power. Haven't previously noticed > whether contention_to_use_the_communications_line can "freeze > out" any of the contenders.] To my mind, there were __only__ > two "foreground tasks" active - the audio stream and Mozilla. > Assuming OS/2 was performing timeslicing, I would expect CPU > processing power to be SHARED (50-50) between these tasks. > > Yet the audio stream *did* drop out on occasion. Was that > because Mozilla was giving itself __higher__ priority ? > > If so, can the __user__ somehow limit how greedy Mozilla becomes ? > Or, if my audio stream is more important to me than Mozilla, must > I manually RAISE the priority at which the audio stream task runs ? > > mikus
