[haiku-appserver] Re: deadlock
- From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Wed, 06 Apr 2005 17:42:38 +0300
Hi,
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? :-)
b-bye,
Adi.
Other related posts:
