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

[asif saeed]

Hi Lindley,

Don't want to give any feedback? :) Well, I am still waiting :)

On Tue, Jan 7, 2014 at 9:45 PM, asif saeed <asif.lse2 at gmail.com> wrote:

> 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 years.
>

Basically, I like the way that application used the system queue but I
wonder how would it perform had it been developed using 0MQ! I want your
feedback specifically on this. I hope this is easy for you experts on
this list.

Best regards,
-Asif
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140107/4d7f7d37/attachment.htm>