[haiku-commits] Re: haiku: hrev49843 - src/servers/app/drawing src/servers/app headers/private/interface

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Mon, 16 Nov 2015 17:58:40 +0100

Hi,

Am 16.11.2015 um 17:40 schrieb looncraz:

On 11/16/2015 04:30, Axel Dörfler wrote:

If each window would have its own bitmap to draw in (ie. actual
compositing), the problem would be solved the only way I can see it
being solved for real.
I faintly remember looncraz working on something like that :-)


The exact point of the stall was something I could never find with
certainty, but it seemed to be on the Desktop all window lock - the only
way to get rid of it was to limit how many threads were trying to gain
the write lock. How many were trying to draw was a non-issue (since my
current version still has every app on the system redraw freely, the
only changea being that the Desktop write lock is no longer acquire as
much and the update frequency is greatly reduced).

Sounds like there is a deadlock in your code, which you've made less likely to happen on your specific setup. You didn't fix it. This is the wrong attitude for working on the app_server, though, I hope you agree.

It was possible for me to hit push a couple hundred set_ui_color()
commands (which initiated a redraw in every window at once) and the
system would effectively hard freeze. BUT, if you waited long enough,
the stall would eventually go away.

The easiest solution, conceptually, is just to not share locks (having
gone through this, I now understand a really annoying freeze I was
getting with my compositing branch.. I will need to revisit this now
;-)). Of course, as I suggested, using a MultiLocker for each
ServerWindow is the "proper" solution, but it isn't the easiest to
implement. It would require quite a bit of reworking (and a lot of
headaches along the way).

I don't understand. How can you not share locks? There is data which is shared. It needs to be protected by locks. If you want to allow multiple threads to read the data concurrently, but only one thread to write to it at any time (blocking any readers at the same time), then you need an R/W-lock for this data. That is how the app_server is designed. Where you place the R/W-lock and what you called it is secondary. Since there is just one Desktop object and multiple ServerWindow objects, I decided to place the R/W lock into the Desktop object.

Julian's idea of decoupling off-screen from on-screen windows should
work for his uses, but it doesn't really address the underlying
problem. Drawing does, indeed, happen in parallel, but there are many
cases where the write lock is needed when there is no reason to stop
drawing.

The other option, aside from compositing, is to create a specialized
drawing lock to go with the all window lock. Desktop would then get
bool LockForDrawing() and void UnlockFromDrawing() which would gain read
locks on a MultiLocker and anytime you actually need to prevent drawing
you'd gain the write lock.

Huh? That is how it is designed right now. Only with different naming (since there is actually more than drawing related stuff protected by the R/W lock).

Right now, drawing stalls (for tiny amounts
of time) across the system all the time frequently when it does not need
to do so, just because Desktop needs to service the window list.

I never went so far to obtain detailled analysis on this stuff. And in fact the facilities in the Haiku kernel to do this got added only later. It would be very interesting to get detailled measurements. Have you done any and could you understand from this what is going on and how it could be improved?

Best regards,
-Stephan


Other related posts: