[zeromq-dev] zmq_poll loop break; performance

[Daniel Krikun]

About 2-3 seconds delay. Don't know whether it is dependent on number of
message dispatched, I'd tried in a pilot only, which was about 20 messages.

On Tue, May 1, 2012 at 5:12 PM, Chuck Remes <lists at chuckremes.com> wrote:

>
> On May 1, 2012, at 4:51 AM, Daniel Krikun wrote:
>
> > Hello,
> >
> > I have the following code to dispatch incoming messages via inproc
> transport in one thread, and to stop the dispatcher from another (main)
> thread:
> >
> >
> > void dispatch()
> > {
> >       zmq::socket_t  control_socket_ ( _global_context, ZMQ_PAIR );
> >       control_socket_ .connect( "inproc://control" );
> >
> >      zmq::pollitem_t items[] = {
> >            { data_socket_, 0, ZMQ_POLLIN, 0 },
> >            {  control_socket_, 0 , ZMQ_POLLIN, 0 }
> >       };
> >
> >       while(1)
> >       {
> >                zmq::poll( items, 2)
> >                if(items[0].revents & ZMQ_POLLIN)
> >                {
> >                              // ... dispatch incoming messages ..
> >                }
> >                if(items[1].revents & ZMQ_POLLIN)
> >                      break;
> >        }
> > }
> >
> >
> > In another (main) thread, I send an empty message to "inpoc://control"
> when I want to stop the dispatch.
> > The problem that this stopping is somehow very slow.
> > Why could be that?
> >
> > I am using zeromq-2.1.11 on Windows XP SP3, Visual Studio 2008.
>
> Can you define what you mean by "slow?" Is it 10 milliseconds, 100
> milliseconds, 1000 milliseconds, 10_000 milliseconds?
>
> Also, is it slow *every* time?
>
> Is it dependent upon how long the program has been running OR how many
> "data" messages you have dispatched?
>
> cr
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Daniel Krikun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120501/50cc7db1/attachment.htm>