On 2014-10-08 07:49, David Henningsson 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.
It seems to me like one option could be to do this runtime, by switching
the allocator (this should be possible, right?) to one that checks the
thread context first and fails (or emits a warning) in case we're
currently in a hard real-time safe thread/mode.
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?
So after having looked through the code, I think I can answer the two
remaining one myself (but feel free to correct me if I'm wrong here) :
It looks like this *might* be problematic in the sense that there
*might* be heap memory allocation involved when sending things over the
channel. But it seems to recycle the memory by keeping a list of "unused
list items". So it was not designed for hard real-time usage.
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).
The answer is "no, not as the runtime is currently designed". When a
task deschedules, it seems to wait on a mutex or semaphore. It is not
waiting for file descriptors (like the other mainloops I've seen on Linux).
If it were, it would provide a more flexible approach, including waiting
for pipes, sockets, etc. And eventfds could replace the mutex/semaphore
currently used for channels. It would be interesting to know if there
was a difference in performance though.
// David
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
