
|
[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: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 10 Nov 2005 18:04:13 +0100 CET
mmlr@xxxxxxxx wrote:
> > 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
Very nice :-)
> 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? ;-)
Well, we certainly care, but we have time :-)
Good luck with the R5 output, though - if you need an extra pair of
eyes over that code, just tell me (in case it's in SVN yet).
> > 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.
Cool.
> 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?
That I don't really know. We'll have to determine the value on a
running and optimized system once we're there.
For now, I'd just take some random size, like 64 kB or so (that's
actually still the maximum of what we can put into a port in Haiku,
IIRC) :-)
> 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.
Include syscalls.h in private/kernel/. Have you maybe forgotten to add
'extern "C"' before?
And of course, you can only test this call under Haiku - it won't work
in the libbe_test environment, either.
Bye,
Axel.
|

|