On 4 November 2014 07:43, Alain Rastoul <[email protected]> wrote:
> > > Le 04/11/2014 01:32, Igor Stasenko a écrit : > >> What is zmq sockets? Some kind of wrapper library? Then best i can >> advise is to follow its guidelines, since i'm not familiar with it. >> >> Btw, using (NBExternalArray ofType: 'xyz') is highly expensive, >> please read carefully NBExternalArray class comment, which explains all >> details. >> >> > ZeroMQ is an open source asynchronous inter-process communication messaging > library/framework written in c++ > zeromq sockets should not have been called sockets because they are more > 'endpoints' > or something like that in zmq realms, however, it uses tcp sockets in my > tests and > has different behaviours on linux and windows, I suspect > something different about underlying tcp sockets states. > > Ah, ZeroMQ. Yes, it is a well-known library written in C++. Concerning your problems: i never used it, and i cannot even guess why it behaves differently on different platforms, perhaps you should contact library authors first? Do you create socket via zeromq library, do sockets managed through it? To make sockets to not block the VM, just using a nice library is not enough: you must wire the socket events with VM process scheduling logic through signaling the semaphores etc.. Else you must always use non-blocking calls in C library. > Thank you for the indication about performance, I will take it into account > My first step is just to make experiments that works > to be comfortable with both nativeboost and zeromq. > This experiment is done with two different pharo vm processes > (the client and the server) started manually, and the same > in C. > This library has nice patterns that makes it very interesting from a > parallel computing perspective > (request/response, publisher/subscriber, push/pull , etc). > The guide is here and is worth looking at http://zguide.zeromq.org/page: > all > I know you will be interested in, it has similarities with your > old hydra project > :) > > Well, parallel computing is broad area.. with zillions goals and solutions. The setup you described is not what i wanted to achieve with Hydra. Running multiple instances of same VM ~= running single instance of VM which can manage multiple native threads. But sure thing you can achieve similar results using both approaches. The difference is in how fine grained your control over consumed resources, namely memory and CPU. -- Best regards, Igor Stasenko.
