
|
[haiku-appserver]
||
[Date Prev]
[08-2004 Date Index]
[Date Next]
||
[Thread Prev]
[08-2004 Thread Index]
[Thread Next]
[haiku-appserver] Re: current activity.
- From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Thu, 12 Aug 2004 08:10:09 -0400 EDT
> 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.
> 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.
> 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. My only question is how big a message buffer
we can send over a port.
--DW
|

|