search for: rpcchannel

...9;t worry - I'm too busy with real problems to tackle hypothetical ones. Here's another example of a problem that my proposal solves: 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 wh...

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> wro...

...39;t want to pre-empt anyone else's decision on whether to adopt this. Cheers, Lang. On Wed, Feb 10, 2016 at 1:36 PM, 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? > > > 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...

> > I don't think these are really independent. Whether or not you need to emit > > a diagnostic depends on whether a caller can handle the corresponding error, > > which isn't something you know at the point where the error is raised. > But you do in the diag handler. For example, if you are trying to open > multiple files, some of which are bitcode, you know to