[openbeos] Re: A new BMessage implementation (Message4)
- From: mmlr@xxxxxxxx
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 11 Nov 2005 12:20:19 +0100 (CET)
> 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".
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.
> 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.
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.
>> 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?
Regards
Michael
Other related posts:
