[zeromq-dev] Getting remote_thr to work with short sequences

Steven McCoy steven.mccoy at miru.hk
Thu Dec 2 11:27:08 CET 2010


On 2 December 2010 18:17, Martin Sustrik <sustrik at 250bpm.com> wrote:

> On 12/02/2010 09:05 AM, Steven McCoy wrote:
>
>> ØMQ still seems to follow 2.0 functionality for zmq_close on PUB
>> sockets, such that in remote_thr the sockets get reaped by zmq_term
>> instead of left to linger.
>>
>> Attached is an awful hack to ensure it attains at the time calculated by
>> the provided rate limit.  At least it makes sense even if it is terrible.
>>
>
> Yes. The problem is that 0MQ pushes messages to OpenPGM then it believes
> all the work is done. Thus it allows application to terminate. Obviously,
> there may still be data in OpenPGM's tx buffer, which will be dropped.
>
> The real solution would be to be able to communicate the fact that there's
> nothing more to send in OpenPGM's tx buffer back to 0MQ.
>
>
There is no waiting-to-send buffer in OpenPGM, it's very stream lined.  The
only calls to pgm_sender_t that 0MQ core makes is as follows:

pgm_sender_t::pgm_sender_t
pgm_sender_t::init
pgm_sender_t::~pgm_sender_t

I'll take a wild guess that the 0MQ socket is being created and then the PGM
socket created but the plug called is a deferred call and is only processed
after remote_thr has already closed the socket turning it into a zombie
ready for immediate destruction.

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


More information about the zeromq-dev mailing list