Iterator for Poller #43
Conversation
|
The reason for the existing code is to be able to avoid allocations at runtime (and just have the Events list stack allocated). It would be nice to use an Iterator, but requiring a vec allocation each iteration is not worth it. I don't have any better alternative ideas, but I haven't spent too much time thinking about it yet. |
While switching EventLoop to iterator instead of indexing, I spotted a potencial problem: io_process expects list of events not to change during it's execution, but self is passed as &mut to the handler, making it possible (at least in theory) to break it. After switch to an iterator, this issue is caught by borrow checker actually. I switched the code to collect()ing all events into a Vec as a workaround for now and looking forward to better ideas.
|
I see benefits of both approaches, so I've withdrawn change to event_loop and left only adding iter(). However, I still thing that giving handler ability to break (potentially) event loop is kind of a bug. I'll also rethink it a bit more later. |
|
@carllerche any opinion on the shorter patch? |
|
This seems like it is fine. Quick question though, are you using Poll directly? I think there is some discussion about whether or not Poll is needed vs. just rolling it into EventLoop. I don't know if you have thoughts about that. |
|
I was thinking about using it, yes. EventLoop is too heavyweight if you need e.g. to multiplex 2 sockets for reading :) |
|
Sorry for the delay. I ended up merging this at abbe04d |
While switching EventLoop to iterator instead of indexing, I spotted a
potencial problem: io_process expects list of events not to change during it's
execution, but self is passed as &mut to the handler, making it possible (at
least in theory) to break it. After switch to an iterator, this issue is caught
by borrow checker actually. I switched the code to collect()ing all events into
a Vec as a workaround for now and looking forward to better ideas.