Handle throwing exported functions

[lydia-duncan]

How should we handle exported functions declared with throws?

• [ ] C uses errno instead of throwing exceptions. We'd probably want to do a conversion to use that in the context of exported functions that throw
• [ ] What should Fortran interoperability do? (I don't know where to begin)
• [ ] Python has a concept of exception handling. Ideally, we'd be able to rethrow similar errors in a form that Python can understand.
  • [ ] How would we map Chapel Error subclasses to Python errors? Automatically? Track a known translation set? Export the error hierarchy? Would it be better to indicate that errors originated from Chapel even if they are virtually the same as another Python error?
  • [ ] Would this support rely on the support provided by C interop? Or would we want to special case the generated .a file when we know we are compiling for Python interop?
• [ ] How to handle this in multi-locale interoperability (knowing that the solution may vary depending on the client programming language)? Maybe add an additional ZMQ socket pair for passing thrown errors across the wire? How would we communicate that the error had been caught or failed to be caught by the client? Should we shut down the server side in anticipation? If not, how would we interrupt Python's handling of uncaught errors to shut down the server cleanly?

This should probably be an epic. When it gets prioritized, we'll want to split it into subcomponents

[lydia-duncan]

Note: I do not view this as a priority. I'm mostly tracking the idea because it came up, and my immediate thoughts on what would be involved.

[dlongnecke-cray]

As far as C goes, mapping exceptions to errno (or our own thread local equivalent) makes the most sense to me.

There is also the question of what is generated for user subclassed exceptions. One possibility is to generate an enum over all exception types which may be thrown via exported functions. This would require some AST wizardry.

Right now my RPC protocol looks something like this:

• Socket "main" (client req/server rep): Client/server use this to communicate intent and errors.
• Socket "args" (client pub, server sub): Client uses this to push arguments across the wire.
• Socket "res" (client sub, server pub): Server uses this to push return values across the wire.

The client requests a function call with a positive number on "main", or indicates an error with a negative number. It then pushes the call args across "args". The server attempts to perform the call, then replies with either 0 (success) or an error (and flushes the args socket appropriately). If the server returned success, the client is free to read the result args from the "res" socket. Else it can respond appropriately.

This model seems flexible enough to enable me to do something like, IE, translate Chapel exceptions to C code in the future?

I'll post more thoughts as my prototype comes closer to fruition.

[dlongnecke-cray]

Ahhhh, the nostalgia.

I think if I were to work on this effort today, I would:

• 1) Not allow throws for exported functions when exporting to C, because C doesn't have a concept of exceptions and I don't think we can co-opt errno in a portable way
• 2) Consider allowing Chapel to specify linkage for exported functions, e.g. @linkage("python"), so you could write an exported function that throws specifically for Python (though this raises its own questions)
• 3) push more broadly for auto-wrapping records/classes in Python
• 4) Let the auto-wrapping and linkage spec solve the issue

[bradcray]

Consider allowing Chapel to specify linkage for exported functions, e.g. @linkage("python"), so you could write an exported function that throws specifically for Python (though this raises its own questions)

This is pretty attractive-sounding to me. We've discussed supporting extern("C"), extern("Fortran") to support external declarations in languages other than C in the past, and I think could do the same for export, but this does seem like it could be a good use of an attribute…

That said, I think the compiler should also be given a flag saying what language it's exporting for which would serve as the default. E.g., if I have a program that is only ever going to compile into a Python library, the decorators shouldn't be necessary and C should only be considered the default if that's the kind of library we're creating?

[lydia-duncan]

That said, I think the compiler should also be given a flag saying what language it's exporting for which would serve as the default. E.g., if I have a program that is only ever going to compile into a Python library, the decorators shouldn't be necessary and C should only be considered the default if that's the kind of library we're creating?

This is what --library-python does today, we just have --library mean "C" instead of forcing it to be specified as well