[coyotos-dev] [CapROS-devel] Position statement on IDL bindings

[Jonathan S. Shapiro]

On Mon, 2007-07-09 at 10:17 -0700, Charles Landau wrote:
> At 9:14 PM -0400 7/7/07, Jonathan S. Shapiro wrote:
> >    In the case of procedures returning capabilities, the preferred
> >    implementation will be one of the following:
> >
> >      A. Rotate the return value to the end of the parameter list
> >         as an OUT parameter and change the return type to void.
> >
> >         This is an appropriate simple implementation for C++, for
> >         example.
> >
> >      B. Provide a means, possibly through the IdlEnvironment mechanism
> >         to "allocate" an appropriate location for the return capability.
> >
> >         In this type of binding, the location can be "allocated"
> >         before the call, and the encapsulating language object can
> >         then be returned as the return value.
> 
> Doesn't the caller have to allocate a slot to receive the capability 
> in *either* case?

Yes, but this isn't the heart of the problem. It is straightforward to
call the slot allocator from within the stub. The problem is that you
need to guarantee that the allocated location will later be
*deallocated*, and unless you have GC or some sort of smart pointer
construct for capability references there is no robust way to do that
that I can see.

> >2. For languages that do NOT have native exception handling, IDL
> >    result codes should be returned by the stub, and the nominal return
> >    type (if not void) should be rotated to the end of the parameter
> >    list.
> 
> Good. IIUC this is not a change from the current CapROS IDL compiler.

Yes. That is correct. I had a feeling that might please you. :-)
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC