I experimented with changing generate() to assume an internal buffer, rather than one provided by the caller. This was to make async/threaded behavior simpler -- every thing that could be parallelized comes with its own buffer. But after prototyping an async version of the main traits, I decided that's too complicated, and instead thought about Orchestrator wrapping each entity in a thread and allowing communication with messages (basically the same thing I've been doing to all services). That seems a lot simpler, and it means the core structs can stay nice and simple, knowing nothing about async.
Work: try the message-based solution, and then close this bug wontfix if it works.
Yes, if entities are going to work via anything asynchronous (async/await or messages), then they need to own their buffers. I suppose an async fn could keep a caller-owned buffer around, but right now async appears to be beyond my ability. In my current prototype, an entity takes a NeedsAudio(frame_count) message, adjusts its internal buffer to fit that size, does its work, and then sends a Frames(Vec). Tons of copying and heap usage. Maybe an Arc<Vec<>> could work to reduce some of that?
I made the millionth Rust Actor framework after looking at a few thousand existing ones. Mine is probably awful, but it works for me. An EntityActor wraps an Entity and exposes its traits via messages.
So it wasn't an either-or; it's more of an and. Closing this bug because the research is done and is on its way to production now.
I experimented with changing generate() to assume an internal buffer, rather than one provided by the caller. This was to make async/threaded behavior simpler -- every thing that could be parallelized comes with its own buffer. But after prototyping an async version of the main traits, I decided that's too complicated, and instead thought about Orchestrator wrapping each entity in a thread and allowing communication with messages (basically the same thing I've been doing to all services). That seems a lot simpler, and it means the core structs can stay nice and simple, knowing nothing about async.
Work: try the message-based solution, and then close this bug wontfix if it works.