[llvm-dev] [RFC] Error handling in LLVM libraries.

[Lang Hames via llvm-dev]

Hi Rafael,

What prevents you from using a diag handler in the jit server that
sends errors/warnings over the RPCChannel?


Sorry - this is a non-trivial problem to think through, so to speed things
up, here are the issues:

(1) A diagnostic handler can only exit or continue, neither of which are
sufficient to deal with an error in the general case. You need to be able
to stop and unwind to some point in the stack where the error can be
handled, meaningfully releasing / cleaning-up resources as you go.

(2) Using a diagnostic handler for structured error serialization removes
the cohesion between error serialization / deserialization and the error
types themselves. It also removes the cohesion between serialization and
deserialization: serialization happens in the diagnostic handler,
deserialization somewhere else. All this makes it very easy to forget to
update serialization/deserialization code when error types change, and for
serialization/deserialization to get out of sync with one another.
Diagnostic handlers really aren't designed for this problem.

In my design, anyone building a client/server system on top of ORC can make
any error reportable over the wire by inheriting from some "Serializable"
interface and writing their serialization/deserialization code in the error
type itself. The server can then contain a checkTypedError block that boils
down to:

while (1) {
  if (auto Err = handleServerCommand(Channel))
    if (Err is handleable by the server)
      /* handle it */
    else if (Err.isA<Serializable>())
      Err->serialize(Channel); /* Report it to the client, let them respond
*/
    else
      return Err; /* Bail out of the server loop */
}

Cheers,
Lang.

On Wed, Feb 10, 2016 at 10:55 AM, Lang Hames <lhames at gmail.com> wrote:

> Hi Rafael,
>
> What prevents you from using a diag handler in the jit server that
> sends errors/warnings over the RPCChannel?
>
>
> What would you do with errors that can't reasonable be serialized when
> they reach the diagnostic handler?
>
> And what would you do with the serialized bytes on the client end?
>
> - Lang.
>
> Sent from my iPhone
>
> On Feb 10, 2016, at 10:31 AM, Rafael Espíndola <rafael.espindola at gmail.com>
> wrote:
>
> I recently added support for remote JITing to ORC. There are in-tree
> library
>
> facilities for JITing code into a process on the other end of an abstract
>
> "RPCChannel". What happens if something goes wrong at one end? We want to
> be
>
> able to communicate an error back across the RPCChannel (assuming it's
> still
>
> intact) so the other side can recover or fail gracefully. That means we
> need
>
> to be able to serialize an error with enough information to describe what
>
> went wrong. There's no practical way to maintain a serialization routine
> for
>
> all possible std::error_codes that might come up, even if they were
> powerful
>
> enough to describe everything that could go wrong (which again, being
> static
>
> kinds, they're not). With my proposal however, a JITError base class can be
>
> defined as:
>
>
> class JITError : public TypedErrorInfo<JITError> {
>
> public:
>
>  virtual void serialize(RPCChannel &C) const = 0;
>
> };
>
>
>
> What prevents you from using a diag handler in the jit server that
> sends errors/warnings over the RPCChannel?
>
> Cheers,
> Rafael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160210/9ae5bc50/attachment.html>