[interfacekit] Re: Proposal: Only one thread per application (notwindow) on app_server side without polling

On Sat, 26 Jul 2003 01:40:45 GMT "Marcus Overhagen" <ml@xxxxxxxxxxxx> 
wrote:
> 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.

You may be right. Given that the stacks start at 0xfc005000 and that 
for each ones stack 256 KB are reserved (1 MB for the main thread), the 
limit is at about 250 threads, which is relatively close to when, 
according to my experience, things start to get messy.

Two things come into my mind:
1) Use a cleverer strategy to place the stacks in the virtual address 
space, e.g. have heap and stack growing towards each other.
2) As Axel already said, introduce a function to set the stack size.

> The obvious solution is to have only one thread (or at least only a 
> small 
> number of them per application, regardless of the number of windows 
> (or ports).
> 
> Limitations of the current BeOS and also the NewOS or OpenBeOS kernel
> prevent the use of a Simple WaitForMultipleObjects() call to wait on 
> a number of ports at the same time. That's the reason why one thread
> for each connection port is created on the app_server side.

I'm not so sure about that. There are more advantages of having several 
threads. E.g. if one blocks on a semaphore/port, others still can 
service the application. I'm afraid that having only one app server 
thread per application will worsen responsiveness.

[...]
> When a BWindow needs to transfer data, it does a 
> write_port(window_port, data);
> atomic_add(event_counter_pointer, 1)
> release_sem(event_sem);

You've got a race condition here. If the thread is preempted after the 
write_port() and another thread manages to get through the whole 
transmission procedure, the app server side receival procedure will 
dispatch the messages to the wrong targets. So either a mutex for the 
first two lines is required or one simply sends the target identifier 
with the message, as Axel suggested, which let's you get rid of the 
event counters as well as of the event semaphore -- the port will 
suffice.

Anyway, I'm sceptical about changing the `one app server thread per 
window' model. I see the need for bitmaps, for they are a cheap 
resource in itself and making them expensive by running an app server 
thread for each is not to be justified, I think. But I don't really 
see, why it shouldn't be possible to deal with 1000 or more windows at 
the same time with the old model, given a better address space layout 
and a function to set the stack size.

CU, Ingo

Other related posts: