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

[Lindley French]

I'm pretty new to ZeroMQ myself, but distributed computing is an interest
of mine.

>From what you've said it sounds like the system could be improved. I can't
really offer any more specific feedback than that with the information
available.


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

> 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
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140107/aa6d9d37/attachment.htm>