[zeromq-dev] [2.1.0] encoder hanging in remote_thr tests

Steven McCoy steven.mccoy at miru.hk
Thu Dec 2 06:16:58 CET 2010


On 2 December 2010 12:54, Steven McCoy <steven.mccoy at miru.hk> wrote:

> *remote_thr.exe "epgm://10.6.15.88;239.192.0.1:7500" 100 3*
> pub_t::xsend
> single pipe
> pub_t::xsend
> single pipe
> pub_t::xsend
> single pipe
> pgm_sender_t::pgm_sender_t
> pgm_sender_t::init
> pgm_sender_t::plug
> pgm_sender_t::out_event
> encoder.get_data
> < stall >
>
>
...
570# pos 510 write_pos 0073FDB0 to_write 0
571# pos 510 write_pos 0073FDB0 to_write 0
572# pos 510 write_pos 0073FDB0 to_write 0
573# pos 510 write_pos 0073FDB0 to_write 0
574# pos 510 write_pos 0073FDB0 to_write 0
575# pos 510 write_pos 0073FDB0 to_write 0
...

The encoder is spinning with to_write = 0, it is a design decision whether
it next() must return some data if next() returns non-zero.  An extra
assertion would be handy.

if (!to_write) {
     if (!(static_cast <T*> (this)->*next) ()) {
         *data_ = buffer;
         *size_ = pos;
         return;
     }

*     zmq_assert (!!to_write);*

     //  If beginning of the message was processed, adjust the
     //  first-message-offset.
     if (beginning) {
         if (offset_ && *offset_ == -1)
             *offset_ = pos;
         beginning = false;
     }
 }

-- 
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101202/6e5af68b/attachment.htm>


More information about the zeromq-dev mailing list