For racket-on-chez, will places disappear? And what kind of operations will be future-unsafe (that is, cause a future to stop running in parallel with other work)?

I think it will be easy to implement places using Chez Scheme threads. Different places will not be independently GCed, but the constraints on place communication will mean that the use of Chez Scheme threads is safe.

I’ll defer the quesiton on futures to @spall :slightly_smiling_face:

>future-unsafe (that is, cause a future to stop running in parallel with other work)? Currently a future which uses a continuation function will stop running in parallel; this is to maintain the current future semantics. Also garbage collection will currently require all but the main pthread to halt; for this to change there would need to be modifications made to chez itself.

As for other operations I am not yet sure. Futures are still a work in progress (recently moved them from the chez layer to the racket thread layer).

<http://www.scheme.com/csug8/threads.html>

I would imagine anything described here as pthread safe would also be future safe, and anything that is not described as thread safe could be made pthread safe (future safe) with some sort of locking scheme. My goal is to make as many things thread safe as possible, having used futures in regular racket and struggling to get any sort of parallelism.

Thanks, @spall. After GC completes, would the non-main threads resume running in parallel?

yes they will; and will continue running their work in parallel

just to clarify one thing — what @spall describes is already the behavior of Chez, and it does this rendezvous implicitly

yes, well there is also a requirement for the pthreads that run futures to rendezvous themselves if collect-garbage is explicitly called

so it’s not like Racket is making things any slower there

true this is a chez thing