Handle asynchronous Java exceptions

[alpmestan]

From the JNI spec:

Asynchronous Exceptions
In cases of multiple threads, threads other than the current thread may post an asynchronous exception. An asynchronous exception does not immediately affect the execution of the native code in the current thread, until:

• the native code calls one of the JNI functions that could raise synchronous exceptions, or
• the native code uses ExceptionOccurred() to explicitly check for synchronous and asynchronous
  exceptions.

Note that only those JNI functions that could potentially raise synchronous exceptions check for asynchronous exceptions.
Native methods should insert ExceptionOccurred() checks in necessary places (such as in a tight loop without other exception checks) to ensure that the current thread responds to asynchronous exceptions in a reasonable amount of time.

[mboes]

I'm not sure that we need to do anything special here. I think we can close the ticket. While async exceptions currently never get raised while in the middle of evaluating Haskell code, it's also not something that can be helped. Unless we hook into the RTS to have it ask Java whether async exceptions occurred whenever we reach a "safe point", we can't do better than raising the async exception next time a JNI call from the current thread is made. We can't have timer based polling or anything like that, because the polling would happen in another thread and so be oblivious to the async exceptions thrown to the target thread. What's more, it's reasonable to say that safe points as relates to Java exceptions are fewer and farther between than Haskell safe points. They only occur every time one calls a JNI function.

[mboes]

However, we should at the very least document the behaviour of Sparkle in the face of async Java exceptions.

[mboes]

This issue was moved to tweag/inline-java#4