So, the current options are to have on thread per Socket
Acceptor/Initiator, or a thread per-session. Have you thought about taking
the Thread-Pool approach? For instance, if your app is servicing 15
sessions, a single thread may not be able to keep up while 15 threads would
be overkill. However a Thread-Pool of 3 threads would be adequate.
> Date: Fri, 11 Jul 2003 10:06:51 -0700 (PDT)
> From: Oren Miller <ore...@ya...>
> Subject: Re: [Quickfix-developers] Acceptor / Initiator without self-
> spawning threads
> To: Howard Engelhart <ho...@ex...>,
> qui...@li...
>
> We've considered adding this some time ago, but the
> priority was never very high and never got around to
> it. This could theoretically be added fairly easily
> to the SocketInitiator and SocketAcceptor. Internally
> they both use the SocketMonitor class which has a
> block method. This could be setup as a non-blocking
> call (by setting the timeout to 0 seconds). A doWork
> method would then be able to delegate to it.
>
> --- Howard Engelhart <ho...@ex...> wrote:
>> Hello,
>>
>> From digging around in the code a bit I see that the
>> Initiators / Acceptors
>> spawn their own threads, and have their own internal
>> while loops. Is it
>> possible to use QuickFIX without the necessity of
>> those internal threads?
>> Can I control the threading entirely from outside
>> the library, with looping
>> calls to a DoWork type function on the Initiators /
>> Acceptors?
>>
>> Thanks,
>>
>> Howard
>> ho...@ex...
|
