<div dir="ltr"><div><font><span style="background-color:rgba(255,255,255,0)"><font color="#000000">Hi Rafael,</font></span></font></div><div><br></div><div><font><div style="color:rgb(80,0,80);font-size:13px"><blockquote type="cite"><font color="#000000"><span style="background-color:rgba(255,255,255,0)">What prevents you from using a diag handler in the jit server that<br>sends errors/warnings over the RPCChannel?</span></font></blockquote></div></font></div><div><font><span style="background-color:rgba(255,255,255,0)"><font color="#000000"><br></font></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)"><font color="#000000">Sorry - this is a non-trivial problem to </font></span></font>think through, so to speed things up, here are the issues:</div><div style="font-size:13px"><br></div><div style="font-size:13px">(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.</div><div style="font-size:13px"><br></div><div style="font-size:13px">(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.</div><div style="font-size:13px"><br></div><div style="font-size:13px">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:</div><div style="font-size:13px"><br></div><div style="font-size:13px"><font face="monospace, monospace">while (1) {</font></div><div style="font-size:13px"><font face="monospace, monospace">  if (auto Err = handleServerCommand(Channel))</font></div><div style="font-size:13px"><font face="monospace, monospace">    if (Err is handleable by the server)</font></div><div style="font-size:13px"><font face="monospace, monospace">      /* handle it */</font></div><div style="font-size:13px"><font face="monospace, monospace">    else if (Err.isA<Serializable>())</font></div><div style="font-size:13px"><font face="monospace, monospace">      Err->serialize(Channel); /* Report it to the client, let them respond */</font></div><div style="font-size:13px"><font face="monospace, monospace">    else</font></div><div style="font-size:13px"><font face="monospace, monospace">      return Err; /* Bail out of the server loop */</font></div><div style="font-size:13px"><font face="monospace, monospace">}</font></div><div style="font-size:13px"><font face="monospace, monospace"><br></font></div><div style="font-size:13px"><font face="monospace, monospace">Cheers,</font></div><div style="font-size:13px"><font face="monospace, monospace">Lang.</font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 10:55 AM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Hi Rafael,</div><div><br></div><div><span class=""><blockquote type="cite"><font color="#000000"><span style="background-color:rgba(255,255,255,0)">What prevents you from using a diag handler in the jit server that<br>sends errors/warnings over the RPCChannel?</span></font></blockquote><div><br></div></span><div>What would you do with errors that can't reasonable be serialized when they reach the diagnostic handler?</div><div><br></div>And what would you do with the serialized bytes on the client end?</div><span class=""><div><br></div><div>- Lang.<br><br>Sent from my iPhone</div></span><div><div class="h5"><div><br>On Feb 10, 2016, at 10:31 AM, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><blockquote type="cite"><span>I recently added support for remote JITing to ORC. There are in-tree library</span><br></blockquote><blockquote type="cite"><span>facilities for JITing code into a process on the other end of an abstract</span><br></blockquote><blockquote type="cite"><span>"RPCChannel". What happens if something goes wrong at one end? We want to be</span><br></blockquote><blockquote type="cite"><span>able to communicate an error back across the RPCChannel (assuming it's still</span><br></blockquote><blockquote type="cite"><span>intact) so the other side can recover or fail gracefully. That means we need</span><br></blockquote><blockquote type="cite"><span>to be able to serialize an error with enough information to describe what</span><br></blockquote><blockquote type="cite"><span>went wrong. There's no practical way to maintain a serialization routine for</span><br></blockquote><blockquote type="cite"><span>all possible std::error_codes that might come up, even if they were powerful</span><br></blockquote><blockquote type="cite"><span>enough to describe everything that could go wrong (which again, being static</span><br></blockquote><blockquote type="cite"><span>kinds, they're not). With my proposal however, a JITError base class can be</span><br></blockquote><blockquote type="cite"><span>defined as:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>class JITError : public TypedErrorInfo<JITError> {</span><br></blockquote><blockquote type="cite"><span>public:</span><br></blockquote><blockquote type="cite"><span>  virtual void serialize(RPCChannel &C) const = 0;</span><br></blockquote><blockquote type="cite"><span>};</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br><span>What prevents you from using a diag handler in the jit server that</span><br><span>sends errors/warnings over the RPCChannel?</span><br><span></span><br><span>Cheers,</span><br><span>Rafael</span><br></div></blockquote></div></div></div></blockquote></div><br></div>