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

[asif saeed]

Hi Lindley,

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?

Thanks for your comments. I'd be thankful if you could elaborate more on
this.

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