[zeromq-dev] PeriodicCallback timeout?

KIU Shueng Chuan nixchuan at gmail.com
Sat Jul 5 07:28:10 CEST 2014


Zmq sockets are only to be manipulated by their creating thread.

The add_callback example thus assumes that "stream" was created by the same
thread as the one running the event loop and that your producer was in
another thread.
On 4 Jul 2014 23:55, "Indradhanush Gupta" <indradhanush.gupta at gmail.com>
wrote:

> 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
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140705/81a526ee/attachment.htm>


More information about the zeromq-dev mailing list