Re: [Quickfix-developers] QuickFIX's threading model and multiplexing other sources of events

[K. F. <kfr...@gm...>]

Hello Mike!

On Fri, Feb 1, 2013 at 3:22 PM, Mike Gatny <mg...@co...> wrote:
> On Fri, Feb 1, 2013 at 7:58 AM, K. Frank <kfr...@gm...> wrote:
>>
>> I've built a little test app (that appears to work) that is based closely
>> on the ordermatch example.
>
> What if you use the actual ordermatch example instead, and connect the
> tradeclient to it?  Do you see the same behavior?

That's a fair question.  I will take a look at that when I get the chance.

>> So I don't understand the thread count.  If I follow what you are saying,
>> I would expect two threads: one for the main thread (the while loop
>> that reads the console) and one for the SocketAcceptor.
>
> For ordermatch on linux, you will definitely see only two threads: a thread
> blocked on a socket select() and a thread blocked on a stdin read() (easy to
> confirm with gdb "info threads").

And that's a fair answer.  I don't have a linux system at the moment,
but I will take your word for it.

> I have to assume that the extra threads
> are some kind of behind-the-scenes Windows behavior.

Then something is odd.  I'm not aware of any behind-the-scenes
threads created by windows with ordinary win32 code.  I'm quite
certain that win32 threads don't sneak off and spawn extra
threads.  I don't really know about winsock, but since winsock
(and, of course, sockets in general) date back the the
predominantly single-threaded days, I would also be surprised
if the socket stuff were directly responsible for the "extra" threads.

> Whatever it is, the
> observable situation on linux is the same one you can use as your conceptual
> model for SocketAcceptor: For messages you receive, one thread (owned by
> quickfix) will deliver all messages for all Sessions to your Application
> callbacks.  For messages that you send, whatever thread you call
> sendToTarget() from will be used.  The sendToTarget() method is
> synchronized, so you can call from wherever you like.

Thank you for the further clarification.

Coming back to my original question about design:

Would it make sense then to have a centralized event queue,
serviced, for example, by the main thread, that has a
synchronized pushQueue method that gets called by the
FIX Application callbacks?  (And similarly, a price-feed thread
might also use pushQueue to push price-feed events onto
the centralized queue.)

I'm imagining that that would be something of a standard
design for a QuickFIX application that needs to process a
variety of events, other than just FIX events.

But please let me know if people have found this kind of
design troublesome, and what some better alternatives
might be.

> Mike Gatny
> Connamara Systems, LLC

I appreciate your explanations.


K. Frank