But you can have several message loops. And also from my understanding there is no real use for a system pumping out 700 price/position/volume/whatever updates a second.... So the challenge is not to display 700+ but coalesce it in sensible and efficient way....
I agree from a GUI perspective but the ability to process higher frequency quote data to trigger events is what requires careful design. ie. Chart based triggers or releasing orders based on Level II liquidity etc. In general any event based actions are subject to being throttled by the O/S. Although your application may be multi-threading there is typically only one thread to your broker's back office for execution.
for a proper application 700 events/sec is a large number but not a killer. And having single thread to receive messages is 80s design. This is why my joke about "developers considering a better software" has a good real piece of advice. Anyway it is way off topic. But thanks for the useful links
Good discussion - not too far off topic. This is one example of the back office constraint: OEC API is a multi-threaded library and processes user requests asynchronously, but it should be accessed only from creating thread and serializes responses in form of events (callbacks) to the same thread. Obviously I'm not familiar with each platform's API but suspect most will operate the same for order executions.
I think what is happening there is an STA model. To be able to display any information in the Windows UI you have to marshal call from any processing thread (like a thread which just has received a price update message) to the very same thread you created the window in. But again - this is only UI limitation here and you can have several windows each with its own thread / message pump. The back end shouldnt be single-threaded for an efficient R/T system ever.