*Exclusive* use of zero-copy semantics in RTOS

Feb 23, 2010 2 Replies
D

Hi,



I'm writing another multimedia RTOS and looking through the code I've written that *used* other such beasts in the past (wise move, eh? :> ).



It seems like moving zero-copy semantics *formally* into the RTOS's contract should help improve application robustness -- instead of relying on ad-hoc implementations by the developer.



Of course, this makes it a bit more cumbersome to pass small objects around :< I suspect the interface could be bastardized to support



union { void *, }



thought that seems a real kludge.



But, I really can't see many places (in *this* application) where such small objects would need to be handled (?).



What sorts of experience have other folks had in using formal IPC channels with "small objects"? Is it worth "coloring" the channels to support two different types of interface?



Thx,



--don


Vote
Twitter Facebook LinkedIn
J

just wondered if simple types could be passed as ring buffer queue elements, then some flexibility of sync in the production and consumption of the small type could be possible.

cheers jacko

Vote
Twitter Facebook LinkedIn
D

[snip]

That's what I thought with the "union" issue, above. (i.e., cast each to a void* and pass them through the channel). I'm sure this is more efficient than coloring the channels -- just "less pure" ;-)

But, I was at a loss to find examples in which I was actually passing small objects (i.e., simple types) with such a mechanism. Perhaps because the cost of the mechanism was "so high" that I instinctively built larger objects to pass, in the past (and then bore the cost of NOT doing this "formally") (?)

Vote
Twitter Facebook LinkedIn

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required