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'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
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
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?