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