Fixed a large client side memory leak for app_server memory.
* The areas allocated for BBitmaps were never deleted, even though the app_server deleted its part when the memory got freed. * This resulted in a constant memory increase if the application in question would operate on many changing large bitmaps, like photos. * Since the bitmaps are reference counted, we don't actually know when to delete the areas, so that the app_server now notifies the client whenever that is possible. * This might fix #6824.
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
/*
|
||||
* Copyright 2001-2009, Haiku.
|
||||
* Copyright 2001-2012, Haiku.
|
||||
* Distributed under the terms of the MIT License.
|
||||
*
|
||||
* Authors:
|
||||
@@ -601,9 +601,18 @@ BApplication::MessageReceived(BMessage *message)
|
||||
break;
|
||||
|
||||
case kMsgAppServerRestarted:
|
||||
{
|
||||
_ReconnectToServer();
|
||||
break;
|
||||
|
||||
case kMsgDeleteServerMemoryArea:
|
||||
{
|
||||
int32 serverArea;
|
||||
if (message->FindInt32("server area", &serverArea) == B_OK) {
|
||||
// The link is not used, but we currently borrow its lock
|
||||
BPrivate::AppServerLink link;
|
||||
fServerAllocator->RemoveArea(serverArea);
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
||||
default:
|
||||
|
||||
Reference in New Issue
Block a user