Hey,
If your purpose is to just to display market/order data on a gui then I
wouldn't worry too much about straight line speed. GUIs don't have to
be that fast as the humans reading them aren't that fast. Rendering
the data will be the slowest thing. The queuing approach you've
described seems good to me. If you're only going to have a single GUI
client per TWS then great, although if you wanted to fan out a single
data feed to multiple consumers then you'd need a publisher of the data
as a separate process then manage the multiple subscriptions.
I think you'll be limited in performance only by TWS. It's not a high
speed solution that could support a lot of connections. You'd want to
use FIX I suspect.
If you don't need to scale, then connecting things with buffers and
blocking threads is good enough.
Not sure exactly what you're trying to do but that's my view on what
you've described.
HTH,
G.
On Thu, 29 Jul 2021 21:19:06 -0400
"Eduardo Esteva Kremer" <eekremer@...> wrote:
I am planning on adding a GUI like Qt to the TWS API in C++.
In a nutshell, I see this API has 2 threads: one for receiving
messages (the reader) and another for processing them (the client).
These 2 threads connect with each other through a queue by using
signal/wait.
Instinctively, I would tend to connect the GUI to the *client thread*
because it actually decodes messages and invokes the corresponding
callbacks according to the type of message received. However, because
messages must go first through the queue (signal/wait) I foresee some
delays which could impact the display of real-time data on the GUI.
Another option is to connect the GUI directly to the *receiving
thread*, so data goes straight to the GUI code (no queue, waits...in
between). But this option would force us to call TWS API's decode
functions and callbacks from this thread itself. And this seems a
little unnatural.
Any comments greatly appreciated !!
Ed Kremer
