@michaelmmacleod I’ve never been able to use futures (never had something that was parallelizable using futures, not “numeric enough”), so I don’t know. I’ve heard about people using places, more than futures. If no one here knows, the mailing list might be a good place to ask.

@greg I am actually trying to transition from places to futures, reason being that I thought I could get a little better performance and have a smaller memory footprint with them. They are difficult to work with though, so I think I might just keep using places instead.

I’m not sure if it’s a “someday” option as opposed to “today”, but the Racket-on-Chez build adds OS threads to the mix: https://docs.racket-lang.org/foreign/Operating_System_Threads.html

ffi/unsafe/os-thread ~= you could segfault Racket unlike futures or places

those are really only for use with the FFI

Then it seems that places are probably the solution for now. Looking forward to racket-on-chez though!

@michaelmmacleod maybe look at delay/idle ?

and/or the breaks section just below that

Thanks for the tip about display/idle. While investigating it I created a small example and discovered that kill-thread can indeed terminate running futures;

test.rkt: #lang racket (define size 100000) (define the-bytes (make-bytes size 90)) (define the-thread (thread (lambda () (define the-future (future (lambda () (let loop ([i 0]) (cond [(< i size) (bytes-set! the-bytes i 65) (loop (add1 i))] [else (void)]))))) (touch the-future)))) (sleep 0.0000000001) (kill-thread the-thread) (write-bytes the-bytes) $ racket test.rkt > output.txt

On my computer, output.txt becomes partially filled with ’A’s and ’Z’s, meaning that the future was successfully killed mid-execution. This also means that my initial guess about the cause of the overall issue is wrong. I’m currently trying to simplify the piece of code I’m working with to see if I can narrow down the problem.