[LAD] Looking for an introduction to rt programming with a gui

[Olivier Guilyardi]

On 05/20/2010 08:39 PM, Nathanael Anderson wrote:
>        Cons: Uses a pre-compiler for generating "signal/slot" connections,
>     Several of the core classes (like QString) will spread virally through
>     your code.  Because it's a full framework, it sometimes doesn't mix
>     well (e.g. if you write LV2 plugins based on Qt, as I have, you may
>     uncover some strange bugs).
> 
> 
> As the gui is only used for configuring options, and not interaction
> while the program is running (a restart is fine in this use case) I'm
> leaning to a basic c/c++ daemon with osc i/o (udp, non blocking, brain
> dead easy to use :) ) to communicate with a front end . . . which also
> lets me focus more on fast tracking features into the backend, and at
> lease initially just putting a hacky gui together, with very loose
> coupling between the 2. I know sooperlooper and linuxsampler both
> support modes of operation like this. Any dev's here implement a loosely
> decoupled frontend/backed like this before and run into issues i with it?

Well, this is a bit different, but I made an osc server with liblo in Jackbeat,
and got no obscure issue IIRC.

But I sense that you are a bit afraid about dealing with multiple threads.

And in what you explain you'll still need an OSC thread in your daemon, which is
waiting for OSC messages and dispatches them when they arrive. So you'll have to
implement some kind of (IPC) communication channel between this thread and your
RT thread. GUI or not, you have to deal with this ;-)

Now, because you have an RT thread, there are some traditional IPC approaches
that you can't use here. You can't do any blocking calls in the RT thread, so
the usual mutex/lock-based IPC is not ok.

What I do in this situation is sending messages from one thread to the other
through a jack ringbuffer. This is 100% realtime-safe.

--
  Olivier