[haiku-appserver] Re: input issues

  • From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 14 Apr 2005 17:55:10 -0400 EDT

> Hi there,
> 
> I had a look at how the input_server communicates with our 
> app_server, 
> and even though there is only one obvious bug (input_server is not 
> started by the app_server), there are a lot of things done badly, or 
> at 
> least I think so:
> 
> 1) as I said, the input_server is not yet started by our app_server. 
> This, for example, was the reason why I never got any input; I just 
> didn't know that this part is missing from the app_server
Just simply hadn't been done yet. :) Shouldn't be difficult for the 
initial start. As for restarting it when it's been killed, I'm not so 
sure about that one.

> 2) the input_server creates a new BPortLink (which is not that cheap 
> after all) for every update message, instead of having a local copy
It shouldn't be, but IIRC Jason Vandermark wrote that code, so I can't 
say why it was done that way.

> 5) from what I can tell the thread priorities are a bit high overall 
> - 
> real time threads should really only do very little in order to keep 
> the system responsive
Agreed. I can't say for sure, but probably just a thing that will 
change in the future. The sooner, the better, IMO.

> 6) the input_server should probably have separate "streams" for 
> different devices, although I am not sure if the current architecture 
> allows for this; the input_server should offer what it has, and the 
> app_server should tell the it how to multiplex it into different 
> streams (that way we could support more than one user with separate 
> input devices, which would be nice in combination with dual head)
That paints an interesting picture. Question: would such a setup have 
two cursors, then?

> 7) I can see no reason why LinkMsgReader/Sender are separate from 
> BPortLink, at least aggregate them instead of doing just another 
> pointer reference
I needed to subclass them in order to support sending and reading 
messages sent over an area. If you have a better solution, I'd be glad 
to hear it.

> 8) if we had a slightly improved BMessage, it would be potentially 
> faster for input_server communication as BPortLink - the input_server 
> uses BMessages internally, and they often could just be forwarded, 
> instead of, like with BPortLink need to be rebuild every time (right 
> now, though, their speed should be similar, as the BMessage stuff is 
> not that optimized)
Back when I first started working on the server, I thought we should 
use BMessages all over, but was informed about the performance hit in 
repeated flattening and unflattening. I'd love to have us migrate to 
BMessages if we could go to the BMessage format used in Dano/Zeta for 
R2.

> 9) RootLayer seems to create a new BPortLink for every outgoing 
> message; even if a BPortLink construction currently consists merely 
> of 
> 3 mallocs (LinkMsgReader/Sender + the transfer buffer), this could 
> probably be improved if perfomance becomes an issue
Agreed.

> 10) also, since it's me, I wanted to take the opportunity to remember 
> you that we have a style guide to adhere to. Michael and Stephan 
> seems 
> to know about it at least :-)
Not that I've written any code lately, but we all can use a reminder 
now and then. Thanks. :D

--DarkWyrm



Other related posts: