>I think the port would leak if PROC were to raise an exception.

To my knowledge, this is currently kind of impossible to properly handle, since Scheme doesn’t have ‘finally’. Closest thing is ‘dynamic-wind’ + close it in the ‘out-guard’, but that isn’t quite right since (re)winding can happen because of scheduling (e.g. Fibers) or other reasons other than exceptions, in which case it shouldn’t be closed.

A potential other option is to implement ‘finally’ in terms of exception handling, but even in case of exceptions, sometimes it shouldn’t be closed – if it is continuable and it is continued, then the port shouldn’t be closed.

I think the solution to this, is to make dynamic-wind overridable – the current dynamic-wind would be renamed to primitive-dynamic-wind, dynamic-wind would default to primitive-dynamic-wind but could be overriden (maybe with a parameter), and userspace scheduler libraries can override ‘dynamic-wind’ such that the ‘in-guard’ & ‘out-guard’ is _not_ run when the (re)winding is because of scheduling purposes.

Then, if the user needs a dynamic-wind for things like implementing parameter-like things (e.g. adjust a C thread-local variable with a similar API like parameters), it would use primitive-dynamic-wind, and if it needs a dynamic-wind for things like resource cleanup, it would use ‘dynamic-wind’.

While not quite integrated in Guile like this yet, for practical implementation see:

• https://github.com/wingo/fibers/commit/cc0e84cd56df3b07d378f710df39f8822317a2a2
• https://git.sr.ht/~old/guile-parallel/tree/master/item/parallel.scm#L29
• (what’s missing here, is a way to override Guile’s dynamic-wind in a transparent manner)

Best regards,
Maxime Devos