[BUG] - Ports are seemingly only polled once per event loop

[hasezoey]

Description

From what i can tell, currently Ports (like crossterm) are only polled once per loop in the EventListenerWorker, basically making PollStrategy::UpTo(10) ineffective and having at most 2 events (one port, one tick) when not using extra ports than default input.

Steps to reproduce

Have a tuirealm 1.9 app (or one of the examples) and try to use PollStrategy::UpTo(10), log the amount of messages you get each .tick call and move the mouse a lot over the terminal (#70), observe only having on average 1 event and at most 2 events per call.

Expected behaviour

Should poll a port until it does not return anything anymore, or make it configurable how much a port is polled.

Environment

• OS: Linux Manjaro 23.1.3
• Architecture x86_64
• Rust version 1.76.0
• tui-realm version 1.9.2

Additional information

My guess is this happens because of the following code:

tui-realm/src/listener/worker.rs

Lines 121 to 138 in b33a430

	let msg: Vec<ListenerMsg<U>> = self
	.ports
	.iter_mut()
	.filter_map(|x| {
	if x.should_poll() {
	let msg = match x.poll() {
	Ok(Some(ev)) => Some(ListenerMsg::User(ev)),
	Ok(None) => None,
	Err(err) => Some(ListenerMsg::Error(err)),
	};
	// Update next poll
	x.calc_next_poll();
	msg
	} else {
	None
	}
	})
	.collect();

there the x.poll always only returns one result, and so overall only polling each port once for one event per event loop:

tui-realm/src/listener/worker.rs

Lines 154 to 173 in b33a430

	loop {
	// Check if running or send_error has occurred
	if !self.running() {
	break;
	}
	// If paused, wait and resume cycle
	if self.paused() {
	thread::sleep(Duration::from_millis(25));
	continue;
	}
	// Iter ports and Send messages
	if self.poll().is_err() {
	break;
	}
	// Tick
	if self.should_tick() && self.send_tick().is_err() {
	break;
	}
	// Sleep till next event
	thread::sleep(self.next_event());

and then sleeping after the loop until the interval_time and only then getting the next event, and so basically making PollStrategy::UpTo(10) not a viable thing, whereas PollStrategy::UpTo(100) might get more events on very slow processors, and so makes it very ineffective and potentially inconsistent.