# Help test via snapshots: parallel threads **URL:** \ **Category:** General\ **Created:** [August 25, 2025, 1:03pm UTC](https://racket.discourse.group/t/help-test-via-snapshots-parallel-threads/3920 "2025-08-25T13:03:48Z")\ **Posts on this page:** 1\ **Showing post:** 20
**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 23, 2025, 9:14pm UTC](https://racket.discourse.group/t/help-test-via-snapshots-parallel-threads/3920/20 "2025-09-23T21:14:58Z")
It looks like the non-shared versions involve the creation of a large byte string via `make-bytes`. The large-string allocation triggers a check whether the current thread has any custodian limits, and that involves `current-thread`, which blocks futures but not parallel threads. I found that explanation by using the future visualizer. By default, the future visualizer only shows that `current-thread` was called, but not why. I set the new `PLT_FUTURE_TRACE_DEPTH` environment variable (which I forgot to document, but will!) to 10 to get more context information, and that showed `make-bytes` as the issue. An emerging theme here and in [Why is scheduling this future from a thread slower than scheduling it from the main thread? - #3 by jrkalyan](https://racket.discourse.group/t/why-is-scheduling-this-future-from-a-thread-slower-than-scheduling-it-from-the-main-thread/3940/3) is that futures have various issues that could be resolved with more work, but parallel threads may avoid some issues in the first place. --- _[View the full topic](https://racket.discourse.group/t/help-test-via-snapshots-parallel-threads/3920)._