[haiku-development] Re: Latest changes and general status.

On 2008-04-23 at 02:40:19 [+0200], Bruno G. Albuquerque <bga@xxxxxxxxxxxxx> 
wrote:
> One of the things I have been doing almost every day is to try to build
> Haiku and to track down bugs when I found then. As I mentioned on April
> 1st, I managed to compile Haiku inside itself but based on all activity
> after that it seems it was more out of luck than anything else. Just after
> I managed to do that, Axel started working on fixes for memory Tracking
> and the block cache problems and after that I was never able to go through
> the entire build process again (of course, it was for a good reason. :) ).
> 
> Then recently Ingo found and tracked down a bug where our semaphore code
> was not really working as expected and ended up doing what seems to be a
> complete rewrite of our locking primitives. Well, giving credit where
> credit is due, this was probably, at least on my configuration, the single
> change in Haiku with the most impact since we actually managed to run
> Tracker on it. Not only Haiku feels a lot faster now (compiling it inside
> itself seems to be at least one order of magnitude faster) as the last bug
> I was still getting (a random mimeset failure while building) is now gone.
> I managed, again, to build Haiku (up to a point, see below) inside itself!

Really? 8-O
Thanks for the praise, but I'm utterly surprised, that my changes would 
have any such impact. The semaphore bug should only have been triggered in 
very rare circumstances -- which is probably why it hadn't been discovered 
before (I only saw it when reading the code). Regarding the restructuring 
of the locking primitives, that shouldn't have any noticible performance 
impact yet. Well, our snooze() performs better now. :-P And since a few 
hours also blocking reads from pipes.

[...]
> 2 - I started to get some new KDLs in the block cache after Ingo's
> changes. It seems to be easy to reproduce when trying to start firefox
> after compiling Haiku inside itself. I will also create a bug about this.

I wouldn't rule out that my changes are to blame, but there's already 
#2059, which predates them. Incidently I've just ran into the same bug and 
am trying to analyze it ATM. I haven't come very far yet, though. I've only 
understood that the block cache's pending_notification list has somehow 
become corrupt (the notification's next link has an invalid value which 
causes the crash when removing it from the list).

CU, Ingo

Other related posts: