Re: returning errors

[Marcus Brinkmann]

At Mon, 09 Jul 2007 20:44:25 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> 
> On Mon, 2007-07-09 at 23:42 +0200, Neal H. Walfield wrote:
> 
> > At least on the systems that I have worked with, it is rare to call an
> > IPC stub directly; it is almost always wrapped by a library stub that
> > at least massages the interface a bit and protects the caller from
> > having to set up the environment.  This code is usally written by
> > people in the know.  So, my question is: is this really an issue?
> 
> I believe so, mainly because I believe that adding wrappers to stubs is
> a bad idea -- if you need to do that, then the IDL subsystem wasn't
> designed right. As a case in point, I see no reason at all why the
> CORBA_ENV pointer should ever have existed.

Frankly, almost all applications will not even know what an IDL is,
because they are written to different, portable interfaces.

Then there may be additional requirements imposed by the runtime
system.  As calls are potentially blocking (in case of a faulting
server), you really want them to be interruptible, and this may
require cooperation with the signal subsystem.  Even more so in the
multi-threaded case.

For the native applications, any call which has to manage resources
like capabilities or memory will soon end up being wrapped.  In fact,
need to wrap calls is even more pressing in Coyotos and L4 than Mach
because the capability space needs to be managed in addition to the
memory space.  Only the simplest applications will get away with
either no management at all or implicit management through supporting
data structures.

Or how do you expect a program to know which capability slot to use
for any particular invocation with capability return arguments?

Thanks,
Marcus