At Mon, 09 Jul 2007 20:44:25 -0400, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
