[zeromq-dev] Off-Topic but Relevant - skip if you don't want to reply

asif saeed asif.lse2 at gmail.com
Tue Jan 7 17:45:15 CET 2014

Hi Lindley,

On Tue, Jan 7, 2014 at 9:37 PM, Lindley French <lindleyf at gmail.com> wrote:

> Synchronous processing with an asynchronous framework sounds suspicious,
> but it's impossible to say if it's inappropriate given the level of detail
> available.
> On Jan 7, 2014, at 11:32 AM, asif saeed <asif.lse2 at gmail.com> wrote:
> On Tue, Jan 7, 2014 at 9:08 PM, Lindley French <lindleyf at gmail.com> wrote:
>> There are at least two reasons to put messages on a queue served only by
>> the GUI thread. First, to update a GUI. (Most frameworks don't let you
>> updates GUI elements from background threads, or at least not efficiently.)
>> Second, some systems *cough*Android*cough* have OS callbacks that only
>> occur on the main thread of a program and can't be repositioned to other
>> threads.
>> That said, you haven't given us enough information to really judge if
>> there's a problem with the design or not.
>> On Tue, Jan 7, 2014 at 10:05 AM, asif saeed <asif.lse2 at gmail.com> wrote:
>>> I have had an opportunity to work on a distributed system where the
>>> distributed network/IO library was developed using Windows IO Completion
>>> ports. Internally, the library was certainly performing some high-speed
>>> work but it was shoving its messages into the Windows' GUI message queue so
>>> that the GUI applications will always get each message from the distributed
>>> system into its GUI Queue. This almost completely makes code of such a GUI
>>> application using that library single-threaded as the application gets each
>>> message sequentially - like all other regular GUI messages/events it gets
>>> from its GUI Message queue and handles sequentially.
>>> Secondly, the domain logic of application is mostly request-reply and
>>> due to this quasi-single-threaded approach, it does not proceed until it
>>> gets the message from the distributed system. Even the connections with the
>>> application-specific server applications were established using this
>>> asynchronous approach - don't you think that that should have been done
>>> using a synchronous manner? And if the application does everything
>>> sequentially/synchronously in an asynchronous application then what is the
>>> point of developing it in that manner - asynchronous, that is?
>>> I would be thankful if I could have your opinion on this as I think I
>>> may be mistaken and may be there is a strong good reason the way things are
>>> this way and may be you can tell me those possible reasons.
>>> And, yes, I believe, using ZeroMQ would have been much faster in such as
>>> scenario.
> Well, that system was on Windows and all the distributed applications were
> __server__ applications using MFC's document view framework style. Though
> there was no need for the GUI but whoever did that knew only MFC doc-view
> framework so they did server apps that way. The platform was windows. There
> was only one app - the front-end - where the GUI did matter.
> My point is that if you queue up your application messages in the GUI then
> that results in GUI corruption/freezes in cases where your application is
> getting too many messages. And, what about the sequential/synchronous-style
> processing in an asynchronous app? What about that, Lindley?
> Well, it was a trading system platform with all the usual distributed
server applications. But all that - all of it - all apps - was in MFC GUI
running on Windows. Fortunately, the load was not that high but some
scenarios would just choke the GUI queue.

I still await good feedback from this mailing list. Basically, I want to do
better. I guess there must be other companies in my part of the world that
are doing things like this. So, your feedback is important in this respect
as, I believe, that people on this list have been working on messaging
systems and distributed systems (including the trading systems) for so many

Thanks for the feedback in advance,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140107/ea6fbedc/attachment.htm>

More information about the zeromq-dev mailing list