On Mon, Feb 11, 2013 at 8:16 AM, ustulation <ustulation@gmail.com> wrote:
The Gui is in Qt and Api is in boost. The Gui is meant to sit on top of Api.
One of the functions of Api is to do network level data management, process
data in certain ways and communicate with the Gui (ie., bridge Gui with
other end of Api). To keep the GUI from freezing Api does it's work in a
separate thread. If both Gui and Api had used Qt, communication would have
been easier with cross-threaded signal-slot mechanism of Qt. Api emits and
returns immediately and vice-versa. So none would be blocked unless
explicitly specified (*Qt::BlockingQueuedConnection*). I've been using boost
only since a while back as it was required to code new Api in boost. How do
i achieve this mechanism in *boost <--> Qt communication*? Api is going to
be header+static_library and so Gui and Api will produce single executable.
I have to support Linux, Windows and Mac minimum.


I'm doing something similar in one of my projects and after trying several ways I finally got to this (TLDR: make Api a black box):

 1. totally isolate Api so that there is no way for Qt code to get data inside it without "requests".
 2. Allo Api functions should be thread-safe.
 3. Api exposes a simple event pump function. Each time the Qt code calls this function, it returns event objects or nothing if nothing changed.
 4. In the Qt part, call the Api event pump function as often as possible, using a timer, so that it's always in sync with the Qt thread.
 5. Api never exposes functions returning data. It either don't return anything OR return std::future<MyData> or something similar.
 6. Each call to Api functions is a request. The result will be provided through events OR using futures or similar constructs.
 7. Api can (but is not forced to) use one or more threads inside it's mechanisms. The important thing is to hide from outiside the fact that it do use multi threading or not.
      Isolate Api totally.

This way, each function from the Api is a request to do something, and each event object retuned by the event pump is a signal.
Make sure the event objects are copyable and hold data that are copyable: never share data between inside Api and outside it.

So far it  works for me but I used this architecture for a short time so I'm not sure yet if it's future proof.

Hope it helps.

Joel Lamotte