2005-06-28 16:55:16 +04:00
|
|
|
/*
|
* Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-03-18 16:43:26 +03:00
|
|
|
* Copyright 2001-2006, Haiku.
|
2005-06-28 16:55:16 +04:00
|
|
|
* Distributed under the terms of the MIT License.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Ingo Weinhold <bonefish@cs.tu-berlin.de>
|
|
|
|
*/
|
|
|
|
#ifndef _APPLICATION_PRIVATE_H
|
|
|
|
#define _APPLICATION_PRIVATE_H
|
|
|
|
|
* Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-03-18 16:43:26 +03:00
|
|
|
|
2005-06-28 16:55:16 +04:00
|
|
|
#include <Application.h>
|
|
|
|
|
2006-04-26 00:12:06 +04:00
|
|
|
struct server_read_only_memory;
|
|
|
|
|
* Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-03-18 16:43:26 +03:00
|
|
|
|
2005-06-28 16:55:16 +04:00
|
|
|
class BApplication::Private {
|
* Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-03-18 16:43:26 +03:00
|
|
|
public:
|
|
|
|
static inline BPrivate::PortLink *ServerLink()
|
|
|
|
{ return be_app->fServerLink; }
|
|
|
|
|
|
|
|
static inline BPrivate::ServerMemoryAllocator* ServerAllocator()
|
|
|
|
{ return be_app->fServerAllocator; }
|
2006-04-26 00:12:06 +04:00
|
|
|
|
|
|
|
static inline server_read_only_memory* ServerReadOnlyMemory()
|
|
|
|
{ return (server_read_only_memory*)be_app->fServerReadOnlyMemory; }
|
2005-06-28 16:55:16 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
#endif // _APPLICATION_PRIVATE_H
|