"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.