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

Lindley French lindleyf at gmail.com
Tue Jan 7 17:37:07 CET 2014


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:
> 
> 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
> 
> _______________________________________________
> 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/3ac2c093/attachment.htm>


More information about the zeromq-dev mailing list