[haiku-appserver] Re: Shared Memory Allocation

"DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx> wrote:
> > 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?

That's exactly the scenario for what I suggested - it's exceptional 
anyway, and therefore probably ways faster than if there were any copy 
involved.
Dano switches to creating area on the fly for BMessages over 64kB 
(IIRC) - I haven't made any tests yet (especially not with our kernel), 
but that seems to be the amount where this is actually faster than a 
standard port copy (at least on Dano).

The only problem is probably, that you don't know before that the 
BShape will need that much space, and resize_area() is not exactly the 
most reliable call to compensate that. You could allocate areas in 
chunks (maybe 128 kB) and give the list of those to the app_server - in 
any way, that would need some real world tests.

Bye,
   Axel.

Other related posts: