Re: [Quickfix-developers] Calling user code in quickfix thread

[Sridhar V. <sva...@li...>]

Thank you for the response. This is definitely a good option. I am not
sure of the performance cost since the QF thread would block on every
message.

Is there any case here were we could deadlock if the worker thread tried
to call some QF API. i.e, does QF hold onto any locks before calling the
callback?

Could happen if QF did the following:
QF thread: (Hold some lock L1) -> invoke say QF::fromApp callback ->
callback blocks on semaphore=20
Worker thread: -> process fix message or some other BL message -> call
QF API requiring lock L1 as part of processing, and we are dead locked.

I don't see QF holding any lock before calling the callback from looking
at the code, but I want to be sure that this is the case for all
callbacks and we can have a reliable mechanism.

Thanks,
-Sridhar Vasudevan

________________________________________
From: Brian Erst [mailto:azz...@ya...]=20
Sent: Monday, March 26, 2007 10:59 AM
To: Sridhar Vasudevan; qui...@li...
Subject: Re: [Quickfix-developers] Calling user code in quickfix thread

Alternatively, you could create a separate thread that does all your
business logic needs, but enforce a "single work unit at a time" mode
for processing QF units.

For example, you create a worker thread that reads "work commands" off
of an internal queue. You create two synchronization objects: a "FIX
message processed" (initially set to "false") auto reset event and a
"work unit queued" semaphore (initially set to 0).

Whenever you need to do some work (process a FIX message, do your other
processing), you create a "work unit object" that contains the type of
work you want to do (process FIX msg, do other thing) and the data
needed to perform the task. You place it on the internal work queue and
raise the semaphore.

In the case of a FIX message, you then wait on the "FIX message
processed" event - blocking the thread until the job is done.

The worker thread blocks on the semaphore. When the semaphore is raised,
it does its job and, if the job was processing a FIX message, it raises
the "FIX message processed" event, freeing the QF thread. You then loop
back to the semaphore block.

Now, QF will only send you a single message at a time to your worker
thread, which also does all your other business logic work. In this
example, your non-FIX BL thread can queue multiple work units at a time,
but you can modify that by making the "FIX message processed" event more
generic. Add a secondary event to allow you to interrupt the semaphore
block (for quick shutdowns) and you've got a simple, workable system.

I write code like that all the time - it turns out to be about 30-40
lines of code, wrapped up in a little class.

- Brian Erst
Thynk Software, Inc.
----- Original Message ----
From: Sridhar Vasudevan <sva...@li...>
To: qui...@li...
Sent: Monday, March 26, 2007 9:36:46 AM
Subject: [Quickfix-developers] Calling user code in quickfix thread
QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html


Hello,
We are using the C++ (1.10.2) version of quickfix to implement an
application which has a fix connection and another messaging connection.
We have a few questions related to quickfix spawning its own thread and
calling all callbacks in the context of the thread it spawned.=20

1. Is it possible to call a user defined callback periodically in the QF
thread, so we can do all other non QF related processing in this thread
itself, for example process messages from our messaging connection, etc?


2. If we were to push all fix messages received in the callback onto a
queue, and do all processing on a different thread, then we run the risk
that if the process is bounced then messages in the queue are lost,
since from QF perspective the message has been processed since the
callback exited successfully, while infact its still queued to be
processed on a different thread.=20
While there are ways outside of QF to get around this, we were wondering
if there was a way we could reliably modify the persisted "sequence
number" from the main thread, such that upon restart it can request
resend of fix messages based on what has really been processed.

3. Another option is to not have quickfix spawn its own thread, but
instead we have a mechanism were we would periodically call some QF
function so quickfix can do its processing, effectively having a single
threaded application.

Are any of these feasible options and if so what will need to be done on
our side?=20

We are exploring these options as we would like to avoid having business
logic code running in multiple threads if that's possible.

Thanks in advance,
Sridhar Vasudevan



------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers