
|
[openbeos]
||
[Date Prev]
[11-2005 Date Index]
[Date Next]
||
[Thread Prev]
[11-2005 Thread Index]
[Thread Next]
[openbeos] Re: A new BMessage implementation (Message4)
- From: mmlr@xxxxxxxx
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 10 Nov 2005 17:56:13 +0100 (CET)
> What about those two items, Michael - do you feel like
> implementing them? :-)
Sure, I fully intend to do so. But first I'd really like to get it all
working together. I'm strugling with the R5 formatted output, it just
doesn't seem to be correct somehow when including some delivery
information. Unflattening R5, Dano, KMessage and Message4 as well as
flattening into to native Message4 works well, just that R5 output is
broken. I suppose it's just a very tiny off-by-one error somewhere, but
I just couldn't find it until now. I guess I'll figure it out sooner or
later. As long as the current implementation works, you all do not
really care about Message4, isn't it? ;-)
> At least zero copy messages for intra application usage
> sounds like a *very* good idea to me.
Yeah, copy on write and such. I suppose the design is very well
compatible with this concept, so it should be at least doable if not
easy.
Also the shared memory for large messages is certainly possible. I'd
place the data and the fields buffer there and send the header through
the port. The same copy on write principle can be applied there. But
what size is a "large message"? Starting on what size will the creation
of a shared area and copying the buffer to it be faster than the port
squeezing?
By the way, how exactly do I get that _kern_writev_port_etc working?
What do I have to include or what prototype do I need to write for
this? I tried with just prototyping it, but it did not feel like
linking. I suppose from userspace this call would be
named differently.
Regards
Michael
|

|