[haiku-appserver] Re: current activity.
- From: Adi Oanca <adioanca@xxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Thu, 12 Aug 2004 19:58:08 +0300
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:
