[openbeos] Re: A new BMessage implementation (Message4)

On Fri, 11 Nov 2005 mmlr@xxxxxxxx wrote:

Shouldn't that merely be a matter of maintaining
a reference count and make a copy of the buffers
when a write operation is going to be performed?

Yes, exactly. That's why I meant "if not easy".

Oh, OK. My English skills might be lacking here, but I think, it means exactly the opposite. Any native speaker cares to clarify: "... should be ... doable if not easy..." -- easy or not?

Another task of course is that the other components of the messaging
system have to be adjusted so that they allow to "attach" a message to
some queue without actually sending it (like in Dano). I don't know if
that is difficult to do or not, as I did not have a look yet.

Shouldn't be too hard. There are already BLooper::AddMessage() and _AddMessagePriv() which could be used. They contain open ToDos though.

And I would think one can send both header and
fields buffer through the port, which saves the
hassle of copying the former -- it probably won't
be that big anyway, even if there are a lot of
data.


I'd say it depends how "a lot of data" looks like. It's possible to have
a lot of data in just one field by having some large or many small
values stored. But it is also possible that there is a lot of data by
having just many fields. In the latter case the fields buffer will grow
significantly.

Sure. I just don't think this will happen in practice. At least I can't really imagine a case. Things like copying a large image into the clipboard or recursively archiving a large object hierarchy should be data buffer heavy only.

On the other hand this could be implemented so dynamic, that if the
fields buffer gets too large it is also stored in a shared area of its
own. I just don't want it to get too "fancy" for the sake of
maintainability.


Agreed.

The same copy on write principle can be applied
there.
Between applications? 

Yes, why not? The same reference counting and copy on write mechanisme
could be employed when dealing with a shared area, couldn't it?

This could be dangerous if both applications (sender and receiver) have full write access to the message. Especially if one is a critical system server like the registrar and the other a buggy application that might write uncontrolled into the shared memory. OTOH, if we could use copy on write areas, that would definitely be cool.

CU, Ingo

Other related posts: