[interfacekit] Re: Proposal: Only one thread per application(not window) o= n app_server side without polling

On Sat, 26 Jul 2003 11:34:46 +0200 Massimiliano Origgi <
origgi@xxxxxxxxxxxx> wrote:
> >Hi, please read everything and comment on this.
> 
> >Every BWindow currently uses the PortLink class to have a connection
> >with the app_server where one thread is reading from the port.
> >This is a problem because a large number of BWindows, or offscreen
> >bitmaps will create a large number of threads in the app_server,
> >which will run out of virtual address space because of this.
> 
> [...]
> >What do you think?
> 
> Interesting idea, but so couldn't we just make things even simpler by 
> assigning one thread per application and have all windows from that 
> application just communicate with that thread? I would add one 
> additional 
> thread per application to perform async bitmap rendering. This way we 
> do even 
> reduce other important OS resources such as ports and semaphores.
> This solution would have slight worse performance in some cases under 
> SMP 
> machines: if 2 windows belonging to the same application need 
> app_server 
> work, they must queue their requests to a single thread, whle with 
> the 
> current BeOS implementation 2 separate threads would work for them.

Yep.

> Anyway I think that this simpler solution would benefit the whole 
> system 
> performance and even make the app_server simpler to write and 
> maintain.

I'm not so sure about that. Having a direct connection between an app 
server and an application entity seems to be a very straight forward 
model. At least not more complex than to multiplex/demultiplex the 
communication.

> While we are at it, i just read the other posts regarding rendering 
> and I 
> have a few ideas to discuss with you:
> app side rendering is a nice idea as it would reduce the load on the 
> app_server, which in turn would 'just' have to coordinate shared 
> resources. 
> Clearly hardware acceleration must be available on the app side.

I don't think, it's a good idea to move too much functionality of the 
app server into the applications. A clear client/server approach will 
e.g. make it easier to transparently implement the feature of running 
remote applications. The proposal for drawing non-off-screen bitmaps on 
the application side does explicitly draw only bitmaps, that can be 
draw locally, on the app side.

> A second step would involve rendering windows off screen: this 
> solution would 
> allow nicer screen updates (ala Dano) and would make later support of 
> OpenGL 
> for screen compositing almost immediate. Clearly we need to allocate 
> gfx ram 
> space for these window bitmaps to take advantage of all hardware 
> features.

I believe, that has already been mentioned and IIRC DW said that it 
should be rather easy to implement.

CU, Ingo

Other related posts: