Missing Poller?

[zsunberg]

Hi, I'm writing a distributed engineering app with ZMQ. Some of my components will need to read from multiple sockets. I gather from the ZMQ documentation that I will need to use a Poller for this, however I do not see this in the Julia ZMQ implementation.

I see the POLLIN and POLLOUT constants are defined, but I don't see anything else. Is this a missing feature?

[Keno]

I believe on the Julia side you should be able to just use multiple Julia tasks, one for each socket. Does that not work for your usecase?

[zsunberg]

Thanks for the tip. That may work - I need to read up some more on Julia multiprocessing.

[stevengj]

This is how IJulia works, since it also needs to read from multiple sockets.

[pearcemc]

poll still seems to be missing. I looked into the source but got as far as Base._FDWatcher and thought this was too internal to start playing with.

[malmaud]

While it's true that Julia tasks can largely accomplish the tasks that ZMQ polling are useful for, I don't see why we still couldn't a polling API like http://learning-0mq-with-pyzmq.readthedocs.io/en/latest/pyzmq/multisocket/zmqpoller.html.

[hustf]

@aviks ; we briefly talked at Juliacon about this.
The asyncronous majordomo pattern is touted as a very robust solution. For stepwise building and testing of a system, it is very helpful to open an independent REPL for each of the main workers.
I have tried looking at implementations in Javascript and Python. But linking the additional c-functions in a good way is a huge and scary step for some of us.

[vtjnash]

As keno and stevengj mentioned above, this pattern is not recommended in Julia. Like nodejs, the simple pattern already "just works" (via Tasks) and doesn't need an additional mechanism to make it parallel (e.g. compare the simplicity of http://zguide.zeromq.org/js:mspoller vs the more complex implementation in python using poller http://zguide.zeromq.org/py:mspoller).

[hustf]

I don't think that enables us to open new processes "by ourselves", e.g. on another computer, and then connect. Which is nice for control freaks or for understanding.

I was not aware of all the functionality in the ClusterManager. There's already a 'broker' implementation extending on zmq.jl so the smart approach is surely to learn to use that.

Ideally, it might perhaps be moved to this package, though. From ZMQCM.jl:

    xpub=Socket(ctx, XPUB)
    xsub=Socket(ctx, XSUB)

    ZMQ.bind(xsub, "tcp://127.0.0.1:$(BROKER_SUB_PORT)")
    ZMQ.bind(xpub, "tcp://127.0.0.1:$(BROKER_PUB_PORT)")

    ccall((:zmq_proxy, :libzmq), Cint,  (Ptr{Void}, Ptr{Void}, Ptr{Void}), xsub.data, xpub.data, C_NULL)