Dan G Knutson (Oct 26 2024 at 19:35): Dan G Knutson (Oct 26 2024 at 19:35):Would it be reasonable to add a way for a host to iterate over all elements of a Roc heap? I'd be happy to work on it if it's just a matter of adding the methods. I'm wondering if there's some reason that api shouldn't exist.
The use case is updating Raylib music streams in RocRay. Raylib expects an update function to be called on each stream each frame by the user. Is there a different way I should be approaching this?
Brendan Hansknecht (Oct 26 2024 at 19:40):You're talking about the heaps in the platform that are used for allocating specific types of objects?
Richard Feldman (Oct 26 2024 at 19:43):well hosts are already in charge of all allocations, so they can already traverse all the allocations if they like (just write down which ones came from Roc)
Richard Feldman (Oct 26 2024 at 19:43):is the idea to tell them what the layouts are too, for example so they could make a tracing GC?
Richard Feldman (Oct 26 2024 at 19:44):if so, that would require roc_alloc being additionally passed layout info (and/or type info), which would have performance implications both for the compiler and for all applications even if they don't use the info
Richard Feldman (Oct 26 2024 at 19:45):so it's something we could theoretically do if desired, but there would be downsides to choosing to start doing it
Dan G Knutson (Oct 26 2024 at 19:52):I don't mean anything that fancy :sweat_smile:. I'm guessing there's something I'm missing about how to do the allocation tracking.
Dan G Knutson (Oct 26 2024 at 19:55):With our current setup, I can imagine keeping around a Vec<RocBox<()>>, but then we'd need something like box_to_resource that returns an Option.
Dan G Knutson (Oct 26 2024 at 19:57):I guess 'roc heap' was too general of a term; I mean I have a ThreadSafeRefcountedResourceHeap<bindings::Music> and I want to call a function on each still-alive thing in there.
Brendan Hansknecht (Oct 26 2024 at 20:55):The only concern is that it may be very sparse which could make scanning it really slow
Brendan Hansknecht (Oct 26 2024 at 20:56):But should function just fine
Brendan Hansknecht (Oct 26 2024 at 20:59):There is not an efficient way to tell if any given node is allocated when trying to walk linearly
Brendan Hansknecht (Oct 26 2024 at 20:59):Cause you just have a free list (which is a linked list and could be in any order).
Brendan Hansknecht (Oct 26 2024 at 21:00):So you would have to check the entire freelast to know if any given node is allocated unless you have another trick to know if a binding::Music is allocated vs freed
Brendan Hansknecht (Oct 26 2024 at 21:01):Probably the vec of RocBox is easier and would work better. Just push on alloc. Pop on dealloc. Make sure to swap to end to make pop fast.
Dan G Knutson (Oct 26 2024 at 21:13):Sounds like I was missing that we can compare that rocbox against the c pointer in dealloc. Edit: I think I'm still missing things here but I'll just try things out.
Dan G Knutson (Oct 27 2024 at 01:52):Coming back to this after building part of it out, I still don't see how to compare the RocBox we get from ThreadSafeRefcountedResourceHeap and hold on to, with the c_ptr passed to roc_dealloc. I feel like there's a missing unsafe RocBox::as_ptr method, or a similar trait impl that does exist somewhere I'm not seeing.
Brendan Hansknecht (Oct 27 2024 at 05:05):Ah yeah, I think I always edit roc std to make the inner pointer public. It is pretty silly that it isn't in the platform
Brendan Hansknecht (Oct 27 2024 at 05:06):I guess the heap probably gets the pointer by just mem transmute?
Brendan Hansknecht (Oct 27 2024 at 05:06):A roc box literally is just a pointer
Dan G Knutson (Nov 30 2024 at 17:53):I opened a PR adding a helper function for this here; let me know if that's not the appropriate way to go about it.
Last updated: Jun 16 2026 at 16:19 UTC