Message Boards Message Boards

2
|
4691 Views
|
2 Replies
|
4 Total Likes
View groups...
Share
Share this post:

LibraryLink: How to use a WSTP connection when an abort is in progress?

Posted 9 years ago

I am using getWSLINK() (incorrectly documented as getWSTP()) in my LibraryLink program to evaluate Message, Print, etc. and print debugging information, errors, warning and other things (see here).

After I made my processing functions abortable (AbortQ), I ran into a problem: if the WSTP handling functions were called while an abort was in progress, the WSTP connection somehow got broken for good. It wasn't usable anymore, not even after the abort has finished. MLClearError didn't recover either.

Does anyone have experience with this and can you explain what is happening when we try to use WSTP functions from LibraryLink during an abort?

Is there any way at all to force processing the WS link and still Print some information while an abort is in progress? (I am hopeful because of the existence of AbortProtect.)

For now I put an if (libData->AbortQ()) return; at the beginning of all these printing functions to avoid breaking the MathLink connection.

(This came up while working on LTemplate and the packages I use it in.)

POSTED BY: Szabolcs Horvát
2 Replies

Thank you for the response. This confirms that I should check libData->AbortQ() before trying to use the link form getWSLINK().

Just a short explanation of how I ended up (inadvertently) trying to use the link in the middle of an abort:

I am working on an igraph LibraryLink interface. All igraph functions return an error code (just like MathLink functions). I wrapped them all in a function that checks the error code and reports any errors. The reporting is done by calling Message through getWSLINK, almost exactly like in the documentation example here. At a later point I added abort support. igraph functions will return an error code when aborted, so due to how things were set up, my program attempted to report this by calling Message through WSTP. Now I just check for aborts at the beginning of the message function.

POSTED BY: Szabolcs Horvát

First, you should make sure you're using 10.2. There was a serious bug in earlier versions that didn't handle LinkObjects correctly in an abort scenario.

Second, what you're trying to do really is, if possible, completely inadvisable. When you call back into the kernel, you're calling directly back into code which aggressively is checking for aborts, and really, really wants to fail and throw $Aborted if that happens. You could wrap your invocations of the LibraryFunction objects in AbortProtect. In that way, you can guarantee that if an abort happens, either your function will never be called, or that the abort will not be handled inside your function (including in the callback processing).

And, yes, one of the things that will happen in an abort is to throw away your link. Why? Because an abort may have happened in the middle of link writing/reading operations. Which means that the link is now in an uncertain and unrecoverable state. This scenario is carefully avoided in the Mathematica code proper, but as far as the kernel is concerned, a DLL has been handling that link doing heaven knows what with it, so its state really is unknowable.

POSTED BY: John Fultz
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract