Re: [Boost-users] Communication between QThread and boost threads

Subject: Re: [Boost-users] Communication between QThread and boost threads
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2013-02-12 09:42:08

On Mon, Feb 11, 2013 at 8:16 AM, ustulation <ustulation_at_[hidden]> 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