[zeromq-dev] PUB/SUB question with IPC
Martin Townsend
martin.townsend at xsilon.com
Wed Jul 2 21:33:54 CEST 2014
Hi Pieter,
Thanks for the swift reply. I'll give it a go. Another quick question,
the process could decide to do something else for minutes maybe even
hours, would this upset the subscriber or even the publisher or would it
just fill up it's receive queue? I just want to know whether it would
be better to implement a thread to just process the measurements or my
preference would be to just set the subscriber queue to something like 4
and then when the process needs to just empty the queue like you
suggested and keep the most recent result.
Best Regards,
Martin.
On 02/07/14 17:16, Pieter Hintjens wrote:
> Simply empty the receive queues every time you read (do a non blocking
> recv until there's no message), and keep the message that's most
> useful to you (e.g. the latest one).
>
> On Wed, Jul 2, 2014 at 6:11 PM, Martin Townsend
> <martin.townsend at xsilon.com> wrote:
>> Hi,
>>
>> I want to use the pub/sub pattern for interprocess communication.
>> Basically I have one application reading measurements and then posts it
>> to a number of other processes at a fixed rate of every 500 milliseconds.
>>
>> One of the subscribing processes is only interested in reading every 2
>> seconds. As it queues you get a time lag. I tried setting the
>> ZMQ_RCVHWM socket option to 1 to just drop old messages but this doesn't
>> work. I suppose I could just create the socket, read the current
>> message and tear it down but I was wondering if there is a better way or
>> should I just be using some other IPC like shared memory?
>>
>> Best Regards,
>> Martin.
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
More information about the zeromq-dev
mailing list