Consider whether Poll is needed or should be rolled into EventLoop about mio

[rrichardson]

I should note that the iterator could probably be made into the Selector as well.

[dtantsur]

Let me repeat my comment here: EventLoop is too heavyweight if you need e.g. to multiplex 2 sockets for reading. Also, poller is a commonly used abstraction IMO, so people will expect to find it.

[rrichardson]

That's fine. But use Selector instead of Poll. They are effectively
identical.
On Nov 14, 2014 3:15 AM, "Dmitry Tantsur" [email protected] wrote:

Let me repeat my comment here: EventLoop is too heavyweight if you need
e.g. to multiplex 2 sockets for reading. Also, poller is a commonly used
abstraction IMO, so people will expect to find it.

—
Reply to this email directly or view it on GitHub
#50 (comment).

[dtantsur]

I would say Selector API is a bit more specific. E.g. passing in a mutable pointer to Events does not look user-friendly, IMO it breaks encapsulation.

[rrichardson]

I'm failing to see how passing something a function a mutable container to
be filled breaks encapsulation.

It actually offers tighter control over how many events one would want to
receive per pass, which is often necessary.

Also, you get your iterator wish, because after select completes, you are
welcome to iterate over it, because its your container.

On Fri, Nov 14, 2014 at 10:10 AM, Dmitry Tantsur [email protected]
wrote:

I would say Selector API is a bit more specific. E.g. passing in a mutable
pointer to Events does not look user-friendly, IMO it breaks encapsulation.

—
Reply to this email directly or view it on GitHub
#50 (comment).

“Science is the great antidote to the poison of enthusiasm and
superstition.” -- Adam Smith

[dtantsur]

I hoped that after leaving C++ development I will never end up using

type result;
get_foo(&result);

instead of

type result = get_foo();

(pseudo-c++).

This API does not look like something I encountered in Rust up until now.

What I expect from a polling object is actually like this https://docs.python.org/2/library/select.html#select.poll.poll

[rrichardson]

There is no way to have the 2nd one with out an alloc at every iteration.
(Unless you give it a mutable vector early on that it keeps returning an
immutable reference to) I'm okay with that.

But even then, you still don't need Poll. There is no reason the Selector
interface can be made to do that.
On Nov 14, 2014 11:33 AM, "Dmitry Tantsur" [email protected] wrote:

I hoped that after leaving C++ development I will never end up using

type result;
get_foo(&result);

instead of

type result = get_foo();

(pseudo-c++).

This API does not look like something I encountered in Rust up until now.

What I expect from a polling object is actually like this
https://docs.python.org/2/library/select.html#select.poll.poll

—
Reply to this email directly or view it on GitHub
#50 (comment).

[dtantsur]

There is no way to have the 2nd one with out an alloc at every iteration.

You mean that Rust can't return values on stack? I'm sure it can.
What I want is (pseudo-Rust):

fn poll(&self) -> &[Event] {
  let len = nix::epoll(&mut self.events);
  self.events[..len]  // not sure about slice syntax here
}

No allocations here IIUC. This will allow exactly the code I expect:

for event in poller.poll().iter() {
  // process
}

Of course I don't insist it should be called 'Poll'. I'm completely sure that making all users write boilerplate code won't benefit mio.

[carllerche]

We are going to be keeping Poll. I think it is useful as a standalone construct.