Zpoller test

[fredoboulo]

No description provided.

[daveyarwood]

Looks good! I think this may close #395. Are these tests modeled after the ZMQ.Poller tests?

Also, food for thought: in the spirit of #387, we might consider removing the ZPoller constructors that don't require you to supply a context. To ensure selector resources are freed, all selectors should be created via a context.

[daveyarwood]

Also, food for thought: in the spirit of #387, we might consider removing the ZPoller constructors that don't require you to supply a context. To ensure selector resources are freed, all selectors should be created via a context.

On second thought, after looking at the ZPoller code more closely, it seems like we're already doing sane things with selector resources here. Every ZPoller constructor requires either a ZContext, a selector, or an existing ZPoller to shadow. Supplying your own selector implies that you have access to the selector and can close it yourself. If you don't want to have to worry about that, you can pass in a ZContext instead, and the context will create and manage the selector for you.

[fredoboulo]

I would keep that part like that for the time being.

My thinking now would be to settle a clearer API: there are a lot of methods isReadable, readable, pollin, ... that are doing exactly the same work, mostly because I still cannot decide whether to stick with old methods naming (pollxxx) and new naming (read/writ[able]) I introduced.