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 <juergen.sauerm...@t-online.de> 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. >> >> >> >> > >
