[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
area)
Just a thought...
bye for now,
Have fun!
Adi.
DarkWyrm wrote:
>>"DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx> wrote:
>>
>>>I just changed our pool allocator from a bunch of C code (and ugly
>>>at
>>>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
>>>and
>>>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
>>>new
>>>area, dump it there, and tell the server to look there, or should
>>>the
>>>client ask the app_server for a memory chunk to write to, write to
>>>it,
>>>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
>>server,
>>clone it there, and delete the area in the client, if you don't need
>>to
>>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:
