On Sat, Aug 4, 2012 at 11:32 AM, andrea crotti <[email protected]>wrote:
> I was wondering the following thing, why is zeromq supposed to be > asynchronous? > > For example when I do > > socket.send or socket.recv isn't my application actually blocking? > They do not block for the actual network IO, which is handled in separate thread(s). The send/recv calls really just correspond to passing pointers back and forth with the io_thread. > The asynchronous that I think about is setting a callback when an event > happens.. > You can get this sort of API by integrating with various eventloops (e.g. tornado in Python, libev, or the zloop in czmq). Basic send/recv are something like a synchronous-looking API onto an asynchronous implementation. > Which leads me to the next question, suppose I want to watch live some > processes and be able to communicate with them, how am I supposed to > query the process? > > My guess is that I need two threads in each process, one listening on > the zeromq sockets and the other one doing the actual job, is that correct? > This will depend on the nature of your application and its eventloop. It's entirely possible that you can integrate zmq sockets into the existing app thread via zmq_poll, or the ZMQ_FD sockopt, depending on the nature of the app. -MinRK > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
