On 2014-10-08 13:02, Allen Welkie wrote:
For your first question, you could enable the "owned-heap-memory" warning as an error for the crate in which you want to avoid heap memory. If this doesn't do exactly what you want, you may be able to write your own lint to do what you want http://doc.rust-lang.org/rustc/lint/
Thanks, that's interesting, but I wonder if that would also help against library calls? I e, if I use a HashMap, maybe insertion and deletion causes malloc() and free() to happen inside that call to HashMap.insert, whereas iterating over the HashMap does not, so I could create my hashmap in the main thread, and then send it over to the real-time thread, as long as I don't change it.
If such fine-grained control is not available, maybe certain objects, or modules, or crates, could be marked as "using heap internally" whereas other items would not be marked as such? And then one could have a warning in case one uses such an item.
On Wed, Oct 8, 2014 at 1:49 AM, David Henningsson <[email protected] <mailto:[email protected]>> wrote: Hi, I'm curious about the possibilities to use Rust for programming real-time audio stuff. Usually one has one small task that runs in high priority, and everything else is handled by a main task. I have a few questions related to this: 1) The real-time audio task should never block when not expected to, so stuff like malloc() is forbidden. Is there a way I can mark a section/module/crate/something of the code as "real time safe", and thus get warnings or errors in case I try to do something that would require heap allocation or other blocking stuff? The rest of the code (i e the main task) should still be able to use the entire libstd. 2) The real-time audio thread might want to receive messages as well. Are channels suitable for this, or are the complications that cause things to be problematic here? 3) When using e g ALSA as your audio API, you usually block waiting on a file descriptor. I was wondering if one would be able to select between ALSA's fd and the channel, thus the blocking part of the real-time thread would look something like: select! ( command = rx.recv() => handle_command_from_main___thread(command), () = alsa.wait_for_avail() => alsa.write_more_audio_to___buffer() ) ...where alsa.wait_for_avail() would somehow tell rust that it should block on ALSA's file descriptor in addition to other things (such as messages on the channel). If it matters, assume native threads (i e, not green threads). // David _________________________________________________ Rust-dev mailing list [email protected] <mailto:[email protected]> https://mail.mozilla.org/__listinfo/rust-dev <https://mail.mozilla.org/listinfo/rust-dev>
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
