[coyotos-dev] CapIDL design issue -- return codes

[Jonathan S. Shapiro]

We are updating CapIDL (the IDL compiler for EROS/Coyotos), and some
issues have come up. There are two issues, but they are closely related.
The first concerns handling of return codes.



Every IDL call returns two values: a result code and a return result. In
Coyotos, non-OK result codes are called "exceptions" in IDL. In effect,
every return is a discriminated union of the form:

  (OK, normal-procedure-return value)
  (except1, except1 value)
  ...
  (exceptN, exceptN value)

The normal procedure return value is a structure having fields for the
return value type and also for any OUT parameters.

In EROS, the return value from the CALL operation is the result code. At
the IDL stub level, there is a choice of designs:

  1. Every call can return the result code as its return value, and
     handle the nominal return value as an OUT parameter. That is:

        idl:  int foo(int arg1);

     turns into:

        c:    result_t foo(int arg1, int *_retVal);

     this was my original design, mainly because it followed the
     convention of the CALL operation, but also because it makes
     error checking easy to do consistently:

         if (! foo(...) )
           handle_exceptional_result();

     unfortunately this idiom does not interact with C++ exceptions
     well.

  2. Every call can return its stated return value, and the exception
     code can come out through the IDL environment structure. That is:

        idl:  int foo(int arg1);

     turns into:

        c:    int foo(int arg1, IDL_env* _env);

     and the error checking pattern in C turns into:

        i = foo(arg1, &IdlEnv);
        if (IdlEnv.resultCode)
          handle_exceptional_result();

     this appears to be the solution that other IDL systems have
     adopted. There is a minor variant in which the IdlEnv parameter
     becomes a thread-local global value, and the extra parameter can
     be "hidden" for convenience (similar, conceptually, to errno).

My opinions:

  * I personally prefer [1], because I like the error checking behavior.
    Unfortunately, it is source-incompatible with most other IDL
    functions, which will make it difficult to port existing code to
    this scheme.

  * I find [2] acceptable, but I note that it will tend to suffer from
    the "unchecked errno" problem.

Questions:

  1. Is it important to be consistent with other IDL systems?

  2. Which way to people think return codes should be handled?


shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC