On Wed, 24 Sep 2014, at 14:12, Clemens Ladisch wrote: > William Light wrote: > > At the moment, when the audio thread (the JACK callback) needs to send a > > message over a channel to another thread, it follows the common codepath > > of appending the message to the channel's ring-buffer and then > > write()ing to the eventfd. I suspect this is not real-time safe, but is > > it something I should lose sleep over? > > Well, you should know how your ring buffer behaves (i.e., if it drops > the message or blocks when it overflows). > > As for the eventfd, it could block only if the counter value > exceeded 0xfffffffffffffffe. I'd guess your ring buffer cannot get > that big.
That's encouraging, okay. > (With the ring buffer and the eventfd, you are implementing what looks > like a pipe. If you need to copy the data to the ring buffer anyway, > and if your messages and the entire buffer fit into the pipe limits > (4 KB and 1 MB), you could simply use a pipe to begin with; see > <http://man7.org/linux/man-pages/man7/pipe.7.html>.) Yes, that's roughly what I've got, I'm implementing something similar to Go's channels (actor message queues, basically). I shied away from pipes initially because I figured that staying in user-space would let me keep tighter control on how quickly things execute. I've been following the JACK recommendation of avoiding "all I/O functions (disk, TTY, network)" as strictly as possible, which is why I'm curious about whether write()ing to an eventfd will imperil me. If I could safely use a pipe instead of an all-memory ringbuffer and signaling mechanism, I may just do that. I'm avoiding blocking, of course, but I'm also worried about the potential scheduling implications of jumping into kernel-mode and back, and also the potential non-determinism of system call execution time. Are these things I should actually worry about? -w _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
