Re: [Bug-apl] Execution properties - "cannot be suspended" bit

[Elias Mårtenson]

I can't say it makes much sense in non-opensource programs either. My guess is that these things are more of a relic of a time when people were experimenting with such things. There is a reason no other languages do this.

However, I do see a different use for "non-suspendible functions". I see it as functions that are guaranteed atomic. I.e. functions that modify global state and may actually corrupt that state if they are suspended. Thus, you should not be able to interrupt them, and in a multithreaded context you'd imagine that it had a big global mutex protecting it.

Regards,

Elias

On 9 July 2014 21:11, Juergen Sauermann <address@hidden> wrote:

Hi David,

thanks, I have changed the code so that all user-defined functions with
the cannot be suspended" attribute at the top of the )SI stack are pop'ed
before a new immediate execution context is pushed onto )SI. SVN 369.

I hope this is what the standard wants - the information about these
cases is rather thin in both the ISO standard and in the APL2 manual.

I am not always following APL2 when it comes to hiding details of errors, locked
functions and similar because some of that does IMHO not make much sense in
open-source programs.

/// Jürgen

On 07/08/2014 05:18 AM, David B. Lamkins wrote:

The ISO spec for the component file interface says: "The functions
described here must be written so that they do not suspend. Any errors
encountered or detected must be passed to the context from which the
function was invoked."

I believe that means that the function's "cannot be suspended" attribute
must be set.

I've arranged for each function in the component file API to have the
"cannot be suspended" bit set using
       0 1 0 0⎕fx ⎕cr 'function name'

Errors in the functions so attributed still display the line number at
which the error occurred. According to pg. 295 of the ISO spec, I should
see only the function name on the state indicator.