CoCoA » CoCoALib

As far as CoCoA-5 is concerned CoCoALib is "external software", and the problem noted in #713 applies as much to CoCoALib as to other external libraries.

• there is a global flag CoCoA::InterruptFlag which is normally false
• there is a function CoCoA::SignalInterrupt which sets the flag
• there is a function CoCoA::CheckForInterrupt which tests the flag; if false, the function simply returns; otherwise it resets the flag, and throws a CoCoA::interrupted exception

CoCoALib authors would then be obliged to call CheckForInterrupt every so often, so that an interrupt will actually take effect within a reasonable time.

There is a slight risk in my proposal above. If SignalInterrupt is called asynchronously while CheckForInterrupt is running, and has just reset the flag but not yet thrown the exception, then the flag will be set while the exception is thrown. This could be rather unexpected.

I suggest that a new class CoCoA::InterruptException be the type thrown. Its destructor could reset the interrupt flag. This should ensure that the flag is reset once the (interrupt) exception handler exits scope. This should have the effect of ignoring any further signals while the exception is propagating and being handled.

Maybe even: the ctor for CoCoA::InterruptException could block all signals (and then reset the flag), and the dtor unblocks them. This fits in well with ctor-dtor corresponding to resource acquisition-release.

Here is a further complication: how to handle several libraries together?
Let us suppose that CoCoALib has a mechanism similar to that outlined above, and that libnormaliz has an analogous system.

Suppose we have CoCoALib+libnormaliz working on a problem, and we want to interrupt the computation. From outside we do not know whether the currently running code is part of CoCoALib or part of libnormaliz; so we want to set both flags to be certain that the running code will see the interrupt.

We must also make sure that all flags are reset when the interrupt is handled. Perhaps the simplest solution is to have a single shared flag; this implies that CoCoALib and libnormaliz must work with references to some common global flag. How to tell them where this flag is? In CoCoALib, this could probably be done via GlobalManager.

Also seems to work with the C5 GUI now :-)

• (A) specify the flag in GlobalSettings which is passed as ctor param to GlobalManager
• (B) specify the flag by calling a mem fn of GlobalManager

Approach (B) is more powerful than approach (A) in that approach (A) can always be replaced by approach (B) but not vice versa (as I discovered when modifying src/CoCoA-5/Main.C)

Is there any sense in offering approach (A)? Perhaps it is best to offer just (B), and add approach (A) later if there is good justification?

John Abbott wrote:

Is there any sense in offering approach (A)? Perhaps it is best to offer just (B), and add approach (A) later if there is good justification?

(I admit I'm not understanding all the implications) my preference was for (B) even before reading John's last comment ;-)