What you could also try is to unload all modules that use Coroutines and in addition to unload the module Coroutines themselves.
This terminates Coroutine support and may lead to a more stable behavior with respect to GC.
In the last couple of days the main activity of my Coroutines module has changed from being 90% development / 10% use to 10% development / 90% use. I am getting far fewer crashes - 1 two days ago.
I have now added Coroutines.Cleanup to my CLOSE section. I don't really understand what it does. The Docu says "sets main.from = NIL". Is that correct?
Robert wrote:And now I got another (small window) TRAP: "illegal memory write [ad = 0000008]" called from Coroutines.Cleanup.
This one can be explained, I think.
Coroutines.Cleanup assumes that coroutines have been started and then main is not NIL. IF main is NIL you get what you have observed.
The fix in Coroutines.Cleanup is simple. It can also be done from the outside, of course.
I have used coroutines (in both Modula II & BlackBox), but not very often, and only have a superficial understanding of them.
I have three ideas (see below) which seem relevant, but inconsistent, so at least some of them must be incorrect. Is there a simple high-level explanation of where I am wrong?
1 - The Kernel is, or should be, sufficiently capable to support the Component Pascal language report.
2 - Adding coroutines required additions to the Kernel.
3 - Adding coroutines did not require changes to the language report.
I don't see any inconsistency. The Kernel is not required or defined by the Language Report. Coroutines are not required or defined by the Language Report. e.g. Gardens Point Component Pascal complies with the report. If a coroutine-like functionaility is required for a GPCP application then that is a capability that has to be available on the platform on which GPCP is implemented (i.e. the .NET framework or the Java Virtual Machine). It doesn't have to be implemented using the Component Pascal language.
Modula-2 was different as coroutines were defined as part of the language.
Right. Coroutines happen to interfere with trap handling and GC. That's why they need Kernel support in some way. Compared to the CP language spec this is an implementation detail of the framework.