# Why is scheduling this future from a thread slower than scheduling it from the main thread? **URL:** \ **Category:** Questions & Answers\ **Tags:** thread, futures\ **Created:** [September 15, 2025, 10:04pm UTC](https://racket.discourse.group/t/why-is-scheduling-this-future-from-a-thread-slower-than-scheduling-it-from-the-main-thread/3940 "2025-09-15T22:04:44Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![mflatt](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/mflatt/32/6_2.png) [@mflatt](https://racket.discourse.group/u/mflatt)\ **Post date:** [September 16, 2025, 1:42pm UTC](https://racket.discourse.group/t/why-is-scheduling-this-future-from-a-thread-slower-than-scheduling-it-from-the-main-thread/3940/2 "2025-09-16T13:42:43Z")
In the case where you create the future and immediately `touch` it within the same thread, it turns out to be unlikely that the future gets picked up by the future scheduler before `touch`, and so the thread that calls `touch` just runs the future directly (i.e., in the green/coroutine thread). When you create a future and then create a thread to `touch` it, then there's enough delay between the creation of the future and the time the new thread reaches `touch` that the future is likely to have been picked up by the future scheduler to run in parallel. So, the thread waits for a result, instead of running the future's computation itself. It certainly seems like there's room for improvement in the scheduler heuristics here! Meanwhile, I can't help thinking that you just want parallel threads. If you'd like to try out that route, see [Help test via snapshots: parallel threads](https://racket.discourse.group/t/help-test-via-snapshots-parallel-threads/3920). --- _[View the full topic](https://racket.discourse.group/t/why-is-scheduling-this-future-from-a-thread-slower-than-scheduling-it-from-the-main-thread/3940)._