[haiku-appserver] Re: Shared Memory Allocation

  • From: Adi Oanca <adioanca@xxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Sat, 04 Sep 2004 21:27:30 +0300

Hi all,

        This is my "on the moment" opinion. I'll tell it very quick because I 
must go to a birthday celebration. :-) Beer for meee! :-))

        IMHO: from the start BApplication should have a shared area with 
app_server - small one start. All shared objects should store, from the 
start, their data in that area. The area will grow as needed and shrink 
to a predefined value if, for 15 seconds or so, only <=50% of it is used.

("15 sec or so" ~= a check when the next we access/set data within that 

        Just a thought...

bye for now,
Have fun!

DarkWyrm wrote:
>>"DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx> wrote:
>>>I just changed our pool allocator from a bunch of C code (and ugly 
>>>that) to a class so we can have multiple pool managers in the same 
>>>application without conflicts. We are going the same route as R5 
>>>setting up a general application area. We will eventually be moving 
>>>BBitmap storage to this shared area to prevent a bad app from 
>>>overwriting BBitmap data in another app, but one question still 
>>>remains: how should we send over a large object? Should we create a 
>>>area, dump it there, and tell the server to look there, or should 
>>>client ask the app_server for a memory chunk to write to, write to 
>>>and then send the message? I'm kinda concerned about overhead and I 
>>>wondered what the rest of you gentlemen thought.
>>You can create the area in the client, send its area_id to the 
>>clone it there, and delete the area in the client, if you don't need 
>>access it anymore from there.
>>Does that fit to what you need?
> That was already part of the plan. The problem is how to manage 
> allocating and deleting memory from this shared space. We already have 
> a working pool allocator to handle the actual management, but what 
> would be the best route to go to allow both sides to do this. Perhaps I 
> can illustrate better with an example. Let's say that we have someone 
> who is incredibly stupid or incredibly evil (or both) who wants to 
> approximate a particular strange BShape using a BPolygon object and 
> does so by storing literally each and every point in the thing and, as 
> a result, the thing occupies 2MB of space. Ouch. Then he tries to draw 
> it using StrokePolygon. Somehow that data needs to get to the server. 
> The only problem is that AFAIK there isn't a way for that much data to 
> fit through a port. Ideally, I'd like to have some way to put the whole 
> AS_STROKE_POLYGON message into an area, and then tell the server where 
> it is. Then, the server only has to look in the area to read the whole 
> thing in -- or perhaps make the call directly from the data in the area 
> to avoid another copy -- and then delete the whole mess so that the 
> memory is freed. How could something like this be coordinated? Is there 
> a better way that I haven't yet thought of?
> --DW
> ---------------------------------------------------------------
> http://www.videomax.ro/  -  Cautam cinefili pentru premiere!

Other related posts: