Commit ff76625

committed

Process timers set for exactly now

This fixes a bug wherein the first timer set for exactly `now` ends up in the `pending` list instead of the `ready` list, eventually resulting in polling with a timeout of 0. Under normal circumstances this bug would trigger very rarely, and when it did would only result in one spurious "loop", since the next time the timers are checked, time will have advanced. However, this bug can cause misbehavior and deadlock in emulated environments. e.g., in the Shadow emulator, time only moves forward when a blocking syscall is performed, so this bug causes deadlock: https://gitlab.torproject.org/tpo/core/arti/-/issues/174#note_2762399

1 parent 36ab1d2 commit ff76625Copy full SHA for ff76625

File tree

1 file changed

-1

lines changed

src
- reactor.rs

1 file changed

-1

lines changed

`‎src/reactor.rs‎`

Lines changed: 4 additions & 1 deletion

Original file line number	Diff line number	Diff line change
`@@ -187,7 +187,10 @@ impl Reactor {`
`187`	`187`	`let now = Instant::now();`
`188`	`188`
`189`	`189`	`// Split timers into ready and pending timers.`
`190`		`- let pending = timers.split_off(&(now, 0));`
	`190`	`+ //`
	`191`	+ // Careful to split just after `now`, so that a timer set for exactly `now` is considered
	`192`	`+ // ready.`
	`193`	`+ let pending = timers.split_off(&(now + Duration::from_nanos(1), 0));`
`191`	`194`	`let ready = mem::replace(&mut *timers, pending);`
`192`	`195`
`193`	`196`	`// Calculate the duration until the next event.`

0 commit comments

Comments

(0)

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Commit ff76625

File tree

1 file changed

1 file changed

`‎src/reactor.rs‎`

0 commit comments