Forums

*Exclusive* use of zero-copy semantics in RTOS

Started by D Yuniskis February 22, 2010
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 *,
	<other_type>
}

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?  <frown>

Thx,
--don
On 23 Feb, 03:33, D Yuniskis <not.going.to...@seen.com> wrote:
> 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? =A0:> ). > > 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 =A0:< =A0I suspect the > interface could be bastardized to support > > union { > =A0 =A0 =A0 =A0 void *, > =A0 =A0 =A0 =A0 <other_type> > > } > > 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? =A0<frown> > > Thx, > --don
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
Hi Jacko,

jacko wrote:
> On 23 Feb, 03:33, D Yuniskis <not.going.to...@seen.com> wrote: >> 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 *, >> <other_type> >> } >> >> thought that seems a real kludge.
[snip]
> 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.
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") (?)