[haiku-appserver] Re: deadlock

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Wed, 06 Apr 2005 17:42:38 +0300


Stefano Ceccherini wrote:
 > I'm not sure you can do that.
 > For example, how would you implement this in BFont ? You can access
 > be_app in BFont, but not (at least, not always) a window (and I guess
 > it's the reason why they locked the BApplication)

        Yup, I know that. I was thinking font related methods should use 
BWindow as a proxy somehow to get datas from the server while 
BApplication's ::Run() wasn't yet been called.
        But, forget that, it's a bad idea!

>>StringWidth() uses 
>>BApplication's server connection and for that it must acquire
>>BApplication's lock.
> BTW, forgot to say that this isn't true in R5. R5's _BAppServerLink_
 > class (which is used for communication in every libbe class) doesn't
 > lock the BApplication, but uses a different lock called "main session
 > lock", which I think is a static BLocker. Maybe that's why R5 works
 > (in this case) and haiku does not.

        That's what I love about this team!!! When I get short of ideas, or 
when I'm in trouble there is _always_ someone to come with a nice 
solution! :-) Thanks JB.

        You are right, this solution is _much_ smoother than what we currently 
have in the tree. This means, some things must be changed in 
BApplication so that when sending something to the server a 
_BAppServerLink_ object should be created instead of locking the looper.

        Okay, who will handle this? :-)


Other related posts: