[haiku-appserver] Re: current activity.

DarkWyrm wrote:
>>   50-50.
>>   Yes, because it's elegant and easy to work with.
>>   No, because, if a window crashes while it holds that area's lock, 
>>it would
>>   affect other windows.
>>   Yes, because that area won't be used that often.
> 
> Not really. I wasn't very clear in the fact that these shared areas 
> would be created for each app. If you look at R5's Application.h, you 
> can see setup_server_heaps, ro_offs_to_ptr, etc. which are all 
> functions to deal with the server heap, which is nothing more than an 
> area shared between the app_server and the app.

        Just because R5 does it this way, it doesn't mean you should do it the 
same way.
        The risk stays the same.

>>   We do that? I though we were using a only-once allocated buffer.
>>   [ having a look at BPortLink... ]
>>   Ahhhh, I'm gonna kick some ass, and that's gonna be Phatz's!
> 
> I just got up a bit ago after not sleeping well last night, so I'm not 
> thinking completely clearly, but I just looked at Attach, and it 
> doesn't look like it does. That is, unless it does it in FlushCompleted 
> or something. I'll have to look at it more later.

        And AdjustReplyBuffer().

>>   I thought we agreed on using a static buffer!!! If I send a BIG
>>   picture/region/polygon to server the buffer will get bigger and 
>>bigger and
>>   then drawing instructions instead of being sent to server, are 
>>cached
>>   slowing down server response. By NO means the buffer should be 
>>greater
>>   then 2K!!
>>   DW, do you agree with Phatz? Why?
> 
> Relax. If that is what BPortLink does, we can add another reallocation 
> check to downsize the buffer if it's above 2K. That way, we could have 
> our cake and eat it, too.

        I really don't think so. There are enough memory 
allocations/deallocations. Better use an area.

> My only question is how big a message buffer 
> we can send over a port.

2MB.


Adi.

Other related posts: