issue-#156 adding Coroutines to BlackBox

[Robert]

And it only happens when you unload the suspended coroutine's module, right?

My normal workflow is:
- Edit
- Ctrl k - Compile
- Ctrl s - Save if no compile errors.
- Unload
- Try new version
& repeat many times ....

The crashes usually occur during the Compile.

[Robert]

What about stopping the coroutine(s) before unloading the module?

Not exactly sure what you are suggesting - I think you mean adding something to the CLOSE section of my module?

[Josef Templ]

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.

- Josef

[Robert]

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]

And now I got another (small window) TRAP: "illegal memory write [ad = 0000008]" called from Coroutines.Cleanup.

[Josef Templ]

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.

Code: Select all

	PROCEDURE Cleanup*;
	BEGIN
		IF main # NIL THEN main.source := NIL END
	END Cleanup;

- Josef

[Robert]

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.

[cfbsoftware]

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.

[Josef Templ]

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.