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

Lindley French lindleyf at gmail.com
Tue Jan 7 17:08:12 CET 2014

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

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:

> Hi,
> 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.
> Thank you very much in advance,
> -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/5377638c/attachment.htm>

More information about the zeromq-dev mailing list