You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix race between executor insert and advanceTime (#1554)
This is a follow up to
#1552 .
The linked PR has a race condition:
If the ExtensionJobs is added to the queue after the alarm is set up,
it is possible that the alarm would fire before the jobs are added.
Fixing this is easy, just set up the alarm after.
However, doing this consistently deadlocks the tests. Why?
The tests uses a fake executor.
In tests, time does not flow naturally, but is forced to increment,
usually by the executor's `advanceTime` method.
There is a race between the test thread advancing the time and
the mock server thread inserting more tasks to the fake executor.
If the tasks get inserted first, all is well.
Otherwise, `advanceTime` doesn't see the tasks,
and they do not get executed.
The fix is to check the "current time" every time a task is inserted.
If the task is inserted "in the past", we run the task immediately.
Doing this still deadlocks the tests. Why?
The fake executor needs to lock the task queue when registering a task.
If the task is inserted in the past, it also needs to run the task.
Running the task might involve sending a requst to the mock server.
A GRPC thread on the mock server might handle the request by adding more
tasks to the executor.
The executor's queue is locked by the first thread,
resulting in a deadlock.
The fix is to lock the queue just long enough to retrieve a task,
then execute the task without the lock.
0 commit comments