Make code safe for continuation capture, part the first. · gambiteer/srfi-231@2876863 Bradley Lucier (03 Aug 2022 15:48 UTC)
(missing)

Make code safe for continuation capture, part the first. · gambiteer/srfi-231@2876863 Bradley Lucier 03 Aug 2022 15:47 UTC

https://github.com/gambiteer/srfi-231/commit/287686398dbf08c13c2c668798bd85830cfe2729

ACTION ITEM AT BOTTOM.  (Sorry.)

The above patch begins my attempt to make the array code safe for
continuation capture with call/cc.

There will be more parts.

This exercise is definitely improving the code.

Many of these changes take code that looks like this:

1.  Allocate specialized array result with correct storage class.
2.  Evaluate array elements one by one and assign them to result array
3.  Return the result array.

and changes it to look like this:

1.  Evaluate all result elements one by one safely into a reversed list
2.  Copy the elements of that reversed list to a temporary specialized
array (with the same domain and with generic-storage-class, because we
can't know whether a more specialized storage-class will hold the elements).
3.  Allocate specialized result array with correct storage class
4.  Copy elements from temporary array to result array.
5.  Return the result array.

In the example I gave previously, this can result in much greater
temporary memory use, up to 192 times in Gambit for bit arrays (which
Gambit reports as 384 times because it has a stop-and-copy garbage
collector, so it reports both space allocated in the old heap and space
that it might need in the new heap if that structure survives GC).

There will need to be some changes to code calling
new-domain->old-domain to set up the indexing to shared specialized arrays.

ACTION ITEM:

After this preliminary work, I'm inclined to have a parameter that tells
the code whether to use call/cc-safe algorithms or not to use
call/cc-safe algorithms.  Perhaps named

use-call/cc-safe-array-algorithms

but I'm open to other suggestions.

Brad