FreeLists / haiku-appserver / [haiku-appserver] Re: drawing thread

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

Gabe Yoder <gyoder@xxxxxxxxxxx> wrote:
> >  ATM invalidating and drawing is done from almost every thread in
> > app_server. IMHO this is not that good as we do need a lot of 
> > locking, and
> > code flow is hard to follow. I propose we have methods like 
> > ::Invalidate,
> > ::Redraw, which if executed from another thread than this 
> > drawing_thread,
> > automatically send port messages for the requested action.

Having it communicating via ports could be more expensive than locking. 
It all depends on how long a drawing operation holds the lock, of 
course.

> Reducing the amount of required locking is probably a good thing, 
> although I 
> am not totally clear on what you are proposing as a replacement to 
> the 
> current system (it might help if I paid more attention to the current 
> implementation of the desktop code).  Could you elborate more on the 
> system 
> that you have in mind?
> One advantage that I can see to having a single drawing thread that 
> receive a 
> bunch of messages is that it could allow us to prevent starvation for 
> access 
> to the DisplayDriver.  If I am not mistaken, under the current system 
> with 
> all of the threads making calls to the DisplayDriver, we could end up 
> in a 
> situation where a thread or group of threads keeps hammering on the 
> DisplayDriver, and another thread never manages to get the lock 
> because 
> everybody else manages to cut ahead in line.  If we have a single 
> thread 
> responsible for drawing, we can just fire off the message and build 
> up a 
> queue of things to do (assuming that there isn't some risk of 
> starvation in 
> passing the messages).  Of course, this whole argument is meaningless 
> if 
> there is some sort of FIFO mechanism on the Lock.

If you are just using semaphores, then yes, there is such a mechanism: 
the lock is granted in the exact same order acquire_sem() has been 
called. You would have the starvation problem everywhere if it would 
have been done differently.

Bye,
   Axel.