Oskar Hahn (Apr 29 2024 at 19:27): Oskar Hahn (Apr 29 2024 at 19:27):When the host calls a Roc function in parallel, is there a way to do arena allocations?
For example, if many web requests are handled at the same time in parallel, each handler calls roc_alloc. As far as I know, there is no way to now, which call to roc_alloc is triggered by which request. So when a request is finished, there is no way to know, what to free. You can not create one arena for each call.
Is there something I don't know about that could solve this?
If not, would it be possible and in the scope of Roc to pass around a "context-pointer"? That would be an usize-value (could be 0, could be a pointer to something). It would be an argument to any function exported by Roc and would internally be past around with any function call. This would be nontransparent to the Roc language, so the application author does not know about it. But this context would be past to the host on every "host"-call. So the signature of roc_alloc would be (context: usize, size usize, alignment int). The same for every other function like roc_realloc roc_dealloc, roc_panic, roc_dbg, and all Effect/Task functions.
This would give the host the possibility to add anything into this pointer. For example an allocator.
If there currently is nothing do distinct the calls from Roc to the host of parallel calls: Is this something you would consider?
Luke Boswell (Apr 29 2024 at 20:16):https://github.com/roc-lang/roc/issues/6382
Luke Boswell (Apr 29 2024 at 20:16):Would this help in this use case?
Richard Feldman (Apr 29 2024 at 20:31):yeah we want to switch to that design!
Richard Feldman (Apr 29 2024 at 20:31):(more details in the issue)
Richard Feldman (Apr 29 2024 at 20:33):as a workaround, you can do it right now by having the host use a threadlocal to store which arena to use, and have roc_alloc read from that (and then change it whenever switching to work on a different request handler)
Oskar Hahn (Apr 29 2024 at 21:15):I did miss this issue. This sounds even better and would solve the problem for me.
The workaround does not work in go, since go does not have threadlocal. The goroutines get past around between all threads.
I will be patience and wait, until this #6382 is implemented.
Richard Feldman (Apr 29 2024 at 21:30):ah good to know!
Last updated: Jul 26 2025 at 12:14 UTC