<div dir="ltr">You could also use a jack_rigbuffer_t, its lock free and hence should be RT thread safe.<div>You could write a known msg into the ring buffer from the RT thread, receive the msg from non real-time thread and do event passing from there.</div><div><br></div><div>-- <br>Regards,<br>Karthik Poduval<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 24, 2014 at 5:39 AM, Tim Goetze <span dir="ltr"><<a href="mailto:tim@quitte.de" target="_blank">tim@quitte.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">[William Light]<br>
>I'm avoiding blocking, of course, but I'm also worried about the<br>
>potential scheduling implications of jumping into kernel-mode and back,<br>
>and also the potential non-determinism of system call execution time.<br>
>Are these things I should actually worry about?<br>
<br>
I've been using pipes for message-passing the way Clemens mentioned in<br>
realtime MIDI and audio threads for years without ever experiencing any<br>
scheduling or blocking problems.<br>
<br>
Cheers, Tim<br>
<div class=""><div class="h5">_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-dev" target="_blank">http://lists.linuxaudio.org/listinfo/linux-audio-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div><br>
</div></div>