1. Home
  2. Embedded Programming
  3. *Exclusive* use of zero-copy semantics in RTOS

*Exclusive* use of zero-copy semantics in RTOS

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

Reply to
D Yuniskis
Loading thread data ...

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

Reply to
jacko

[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") (?)

Reply to
D Yuniskis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.