[haiku-development] Re: Re : [RFC] Proposal for the new Haiku scheduler
- From: meianoite@xxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 14 Jun 2007 19:03:05 +0300
On 6/14/07, Star's seed <starsseed@xxxxxxx> wrote:
I think I?ve been misunderstood (certainly my poor English)
Same boat :)
I?ll try to be more explicit
I suggest that, I tread could be run trough 2 different Way:
1 : Automatically by the scheduler
2 : Manually (And that?s why I spoke about fiber) by an other thread
in an other process transmitting its run time.
Aah... Indeed a different issue. I guess what you really meant is a
M:N threading model. And this is already WAY beyond the scope for
Haiku R1.
Imagine
[snip]
Add a process T3 boosting the thread corresponding to the topmost
window (T1) and imagine that the priority is 2 times higher:
No need to. Someone correct me if I'm mistaken, but my understanding
is that BeOS threads can change their priorities at whim.
OTOH, I guess boosting foreground processes *might* *sometimes* be a
good idea, but that calls for a much closer interaction between the
app_server and the kernel. And how that would work (cleanly and
correctly) is unclear to me.
[snip]
Conclusion :
T1 will run 3 times faster than T2 even if they have the same priority
If such situation is to be avoided, the PROGRAMMER should have spawned
the paginator thread with a lower priority, and the
supposed-to-be-very-responsive GUI thread with a higher display
priority
The boost is enhanced with a higher priority of T3
Having an external "arbitrator" thread changing processes priorities
at will can lead to terrible side effects. Imagine a game whose engine
is run in a separate thread, asynchronous to the GUI. The GUI would
eat a ridiculous amount of time that should have been dedicated to the
engine should this arbitrator thread do things like you proposed.
Worse still if the game is windowed and you temporarily switch to your
web browser to read an important email on a resource-intensive web
mail app. Being suddenly killed by the ogre is the last thing one
would want ;)
See ya,
A.
Other related posts:
