[zeromq-dev] Clean shutdown of malamute client zactor in python binding?
Aaron Sokoloski
asokoloski at gmail.com
Thu Feb 4 15:00:14 CET 2016
Of course. At the moment we're protecting access using locks, which is
probably slower and more complicated than message passing but seems to be
working.
On 4 February 2016 at 07:49, Axel Voitier <axel.voitier at gmail.com> wrote:
> Python makes threading sequential, yes. But it can still chops execution
> of a thread in the middle of a function. Such as a function writing to a
> shared buffer to be flushed on a zmq socket later. That is how you can end
> up with messages mixed up if two threads use the same function and/or write
> to the same buffer. (Also happens with reads, of course).
>
> At least with gevent/eventlet you do have sequential execution and you
> control the yielding points.
>
>
> Axel
>
>
> 2016-02-04 14:41 GMT+01:00 Aaron Sokoloski <asokoloski at gmail.com>:
>
>> On 4 February 2016 at 05:45, Arnaud Loonstra <arnaud at sphaero.org> wrote:
>>
>>> As long as it is in Python it will be sequential anyway. In a real
>>> concurrent setup you probably want n:1 topology in between the
>>> webservers and the malamute instance and pass messages, right?
>>>
>>
>> Well, yes, but this is a bit of an uncommon type of web server. Internal
>> use only, so not many clients, but pretty heavy weight processing. I'm
>> trying to avoid having lots of copies of the malamute client, because it
>> needs to cache some pretty big state. So instead the process will have a
>> single client, and webserver threads will query the cache using inproc
>> sockets or something like that.
>>
>> By the way, I think python isn't 100% sequential -- execution of python
>> code is, due to the GIL, but c library code can actually execute in
>> parallel.
>>
>> I might not have the same problem if using something like gevent or
>> eventlet, but making czmq work with one of them is much more work than I
>> can afford to get into right now.
>>
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160204/fb66ae68/attachment.htm>
More information about the zeromq-dev
mailing list