[haiku-appserver] Re: communication

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Sat, 04 Jun 2005 15:54:54 +0200 CEST

Hi Stephan,

"Stephan Assmus" <superstippi@xxxxxx> wrote:
> Numerous problems in our app_server are a result of the _very_ 
> fragile 
> sever<->client communcation.

Yes, I noticed that, too, but no one seemed to care yet :-/
The app_server *must* be the most robust server running on Haiku.

> I also found out about BAppServerLink locking and unlocking be_app's 
> looper in it's constructor and destructor. I don't know if Erik is 
> still around, but maybe him or someone else can explain the reasoning 
> for that? If I remove this locking, BMenus and BAlers don't deadlock 
> anymore. (The whole thing fails at a later point though.)

I think he wanted to save another lock, and I think it's not correct to 
do so this way. But before we change this, we should probably 
investigate in the exact cause of the deadlock.
And It's definitely not acceptable that it creates a new reply port for 
every construction.

> Our app_server comm can freeze up any moment. There only needs to be 
> a 
> message not implemented on the server side, the server wouldn't even 
> have a way to reply with SERVER_FALSE in the message dispatching 
> default case, because the reply port is added as last data in every 
> comm packet, only that the size of the packet is unkown if the 
> message 
> is unkown. (Unless I'm missing something.) If there was a problem 
> with 
> adding stuff to the link, there is no way to tell at a later point. 
> All 
> the code assumes everything went fine. Just look at the problem I 
> found 
> with adding strings.
> 
> I'd vote for a rewrite of the whole comm layer. :-\ Only it is used 
> almost everywhere. Any thoughts?

It has already been rewritten several times, annoyingly. AFAICT 
robustness was never aimed for yet.
Anyway, I don't think we need to rewrite it completely. Since there is 
a StartMessage() we can calculate the size of the message which we 
should just send to the server, too. Then, it would be able to skip 
messages, and never run out of sync. Furthermore, the message code 
alone need to carry infos like "needs reply".
Also, we should replace the almost useless SERVER_TRUE and SERVER_FALSE 
with real error codes, a standard status_t will do here.

Bye,
   Axel.


Other related posts: