[zeromq-dev] PeriodicCallback timeout?

[Indradhanush Gupta]

I had asked out on irc about this problem and "charliebone" made me realise
that I should directly queue the messages on the socket itself.




On Thu, Jul 3, 2014 at 9:44 PM, MinRK <benjaminrk at gmail.com> wrote:

> Why not just queue sends directly? What is the goal of the Queue? For
> threadsafety, you should use the `add_callback` functionality of IOLoop:
>
> loop = IOLoop.instance()
>
> loop.add_callback(lambda : stream.send_multipart(msg))
>
> Then you don't need any polling, it will just send messages when there are
> messages to be sent.
>

However, I don't get this part. How is it different than directly invoking
stream.send_multipart(msg) ?


>
> -MinRK
>
>
>
> On Thu, Jul 3, 2014 at 7:07 AM, KIU Shueng Chuan <nixchuan at gmail.com>
> wrote:
>
>> How about replacing the Queue with zmq sockets? Then you could just add
>> the "consumer" socket to the event loop.
>> On 3 Jul 2014 16:15, "Indradhanush Gupta" <indradhanush.gupta at gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> I am using a PeriodicCallback in pyzmq, that checks a python Queue for
>>> data that needs to be sent.
>>>
>>> It looks like this -
>>>
>>>     self.to_client = Queue.Queue()
>>>
>>>     def check_to_client(self):
>>>         while not self.to_client.empty():
>>>             data = self.to_client.get()
>>>             self.frontend.send(data)
>>>
>>> So, going by the current callback definition, it sends each element of
>>> the Queue until it is empty. I am wondering if this is good. It appears,
>>> that this callback might block if the Queue is very large.
>>>
>>> I have two approaches in mind.
>>>
>>> 1. Send n items, then return, where n = a number that will not block. So
>>> is there an idea on what might be a good number?
>>>
>>> 2. Use a timeout on check_to_client, such that it runs for n
>>> milliseconds and returns. Again what would be a good enough number for
>>> this? But also, is this even possible?
>>>
>>> Any other solution that someone has used before? This appears to be a
>>> very common problem.
>>>
>>> Thanks,
>>> --
>>> Indradhanush Gupta
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>


-- 
Indradhanush Gupta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140704/52923cba/attachment.htm>