Re: IDL issue - struct return vs. cap return

[Jonathan S. Shapiro]

On Tue, 2007-07-10 at 17:24 +0200, Neal H. Walfield wrote:
> You appear to me to have implied that return by value is somehow
> normal and that return by reference is not.  My observation was that
> structs are often returned by reference, not by value.  I claimed that
> if you want to generally return structs by value, then there are
> scenarios where you also need to modify the compiler--just like when
> returning capabilities by value.

In C, all parameters and return values are passed by value. Period. Full
stop. Don't take my word for it. Check the standard.

In CapIDL, all parameters and return values are *supposed* to be passed
by value. Unfortunately, capabilities are not values.

What we *want* is to have some type cap_t in the same way that we have
int32_t, and we want to be able to copy things of type cap_t around.
Unfortunately we can't, because capabilities aren't scalars. The type is
misnamed. It should properly be called "capref_t".

So the question comes down to: (1) can the stub allocate capability
locations internally, and (2) is it sensible to do so.

It is certainly possible for the stub to allocate locations:

   capref_t someStub(args) {
     capref_t retLoc = alloc_cap_loc();
     SYSCALL(args... retLoc);
     return retLoc;
   }

In practice, the resulting memory management scheme is probably too hard
for programmers to get right in the absence of GC or reference counting.
I don't think that we can successfully automate those in C.

Neal: if you have a proposal here, let me know. My main concern is that
if we cannot efficiently deallocate capability locations, we're going to
end up taking a lot of page faults.