PollItems should have a way to get back their sockets

[apoelstra]

Right now PollItems are frustrating to use because once you know there is data to be read, there is no mechanism to actually read said data (unless you remember the mapping between PollItems and Sockets).

It is possible to write a one-liner function that pulls the sock member out of a PollItem and into a Socket.

[johnliu55tw]

Sorry a newbie question here...
So currently is there any way to access those event-ready sockets? Cause the as_poll_item method of a Socket already immutably borrowed the Socket struct, so even if we have the mapping between PollItems and Sockets, those sockets cannot be accessed still.
Or there is another way to do this?

[DrRibosome]

sigh, just ran into this and was about to open an issue for it.

I agree with @apoelstra . I think the as_poll_item method should simply take a self and wrap the underlying socket, and provide ref/mut accessors to the socket. Then you could poll, easily iterate the poll list and look for revents, and actually respond to them

[rotty]

@DrRibosome: as_poll_item() should not take ownership of the socket, I think. If it did, one could not easily store Socket objects in compound data structures and poll them. It might be possible to add a ref accessor to PollItem, but even that might be tricky due to lifetime issues; I haven't seriously looked into it. In combination with #104, the ref accessor would probably be enough to address the use case described here completely.

However, I think even better would be an improved zmq::poll() replacement -- it could return an iterator over (&zmq::Socket, &PollItem), for example. This would be something for the 0.9 release.

I'll have a look at how hard it is to add the ref accessor as a first step.

[rotty]

Well, I don't think getting a Socket from an PollItem is possible, in whatever form:

• zmq::PollItem needs to be compatible with the zmq_poll_item_t C struct, which means we cannot add any Rusty data to it.
• zmq::Socket is not just a lifetime-anointed wrapper around the C struct, but carries additional state necessary due to ownership tracking.

Given the above, I don't think this feature request is implementable as requested. I'll close this as soon as I have filed a new issue requesting a more convenient poll() API, as this is what the motivation behind this issue is, IIUC.