[haiku-appserver] Re: communication

  • From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Tue, 07 Jun 2005 11:10:00 -0400 EDT

> Sure, that would solve lots of the problems. OTOH it's a lot more 
> expansive, too. BMessages would need to be changed a lot, too, since 
> they currently can't be merged together for a simple port write.
> Stephan proposed to use structs, just like the debug server does. 
> This 
> would lighten the problem as well, but wouldn't solve it as good as 
> BMessages would.
I forgot to mention that we wouldn't change BMessage. Instead, we'd use 
that format for a something like an ServerMsg class which would be used 
only in the places where PortLink is currently used. As for the merging 
thing, I don't think it would be an issue from what I have in mind. A 
SeverMsgQueue could take a ServerMsg as an argument and directly copy 
the message's buffer to the queue's buffer, flushing when full.

> > The original reason for PortLink was a low-overhead messaging 
> > class. 
> > The reason? All the Flatten() and Unflatten() calls had serious 
> > overhead. Be even acknowledged this and changed the format in Dano 
> > which used a flattened format to start at the expense of some extra 
> > space. If this were the case, we could use a format code just like 
> > we 
> > do now and the buffer would contain the message. A queueing class 
> > could 
> > be put together relatively quickly to group write_port calls for 
> > BView. 
> > Thoughts?
> A BMessage would still be substantially more expansive than 
> BPortLink. 
> I have no idea if the system is fast enough to make this difference 
> negligible.
> But I don't think we should do this now - as Adi said, Be used even 
> something simpler than BPortLink. It really only gets to be 
> problematic 
> when we start sending messages over the network, where two clients 
> can 
> have different versions of libbe.so. IOW we would need to never 
> change 
> the size of any "code", but instead using new ones (or make the new 
> fields optional).
> We own the code, so (apart from bugs), we only really need to care 
> about backwards compatibility.
I have a feeling that the reason that Be even used BSession, caching 
aside, was because of performance constraints. Considering the number 
of problems it solves, I'd be willing to live with the size bloat if it 
weren't something like 10+ times larger than before.


Other related posts: