"DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx> wrote: > AS_SERVER_SESSION should never be used. It is cruft left over from > the > BSession vs PortLink debates. There is one unified format, so the > only > thing we should see is AS_SERVER_PORTLINK. I agree. > > And I think that's the way to go, anyway. The app_server usually > > knows the reply port. > I'm totally in agreement of the recent discussions of utilizing one > port for replies. My thought is to have a lock-protected port which > belongs to the BPortLink class - a private port_id declared static > and > protected by a BLocker. Comments? That shouldn't be needed, although it would keep the messaging alive while waiting for an answer. Currently, the BPortLink assumes to be synchronized - the BAppServerLink does this on its own, while other links usually use the synchronization from their parent. IOW, only the BAppServerLink would be able to gain from such a change. > > That should make the app_server a lot more robust. > I've been mulling over how to fix PortLink properly, and there is > another issue with PortLink as it is. There are occasions where a > message protocol has been changed on one side and not the other, and > the client or the server crashes, hangs, or starts using weird data. > There needs to be some way to reduce the problems with attachments. > Here's what I propose: scrap PortLink for something else which we > know > works: BMessage, Dano-style. It's a massive changeover, but I think > it > would also be very much worth it. 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. > 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. Bye, Axel.