New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Execute tasks on SerialExecutionContext outside of a test #2314
Comments
@LeifW |
* Add ExecutionContexts as a parameter to MapDb. For use with ScalaTest's SerialExecutionContext - to make test order more deterministic. Defined a new `ComputeAndBlockingExecutionContext` interface to pass in to MapDb, made QuineDistpacthes a subclass of that, and then added a test-only `FromSingleExecutionContext` impl that uses the same ExecutionContext for both. Used in MapDbPersistorSpec. MapDbPersistorTests times out if I try to use SerialExecutionContext - maybe it's blocking some threads or otherwise relies on multithreading? * Use SerialExecutionContext in RocksDbPersistorSpec too * Switched MapDb and RocksDb to use parasitic ExecutionContext in tests scalatest/scalatest#2314 (comment) * Also convert HistoricalQueryTests to use parasitic ExecutionContext GitOrigin-RevId: d83efbcd7126be0a2ad9f6294a03ab52a5e1c54c
@LeifW As Chee Seng mentioned, you can just override the implicit execution context with another one that serves your needs. I would try ExecutionContext.parasitic, which to my knowledge did not exist yet when we created the SerialExecutionContext, and see if that works for you. |
When using AsyncTestSuite (which provided an implicit ExectionContext with SerialExecutionContext), it may sometimes be necessary to run cleanup code after all the tests have executed - e.g. in
afterAll
. However, if that cleanup code involves dispatching to theExecutionContext
, those won't get run (and thus anyAwait
s will time out).SerialExecutionContext
is private, so I can't invoke therunNow
method directly on there. The way I've hacked around this for now is by reflectively callingrunNow
after the Futures have been dispatched inafterAll
:Perhaps exposing something like that to be more conveniently called in
afterAll
would be nice? (Just makingSerialExecutionContext
not private would be an improvement).I get that this is intended for use during tests, but ExecutionContexts aren't always passed granularly enough for me to use one during test code and another during cleanup / shutdown code.
It seems
ExecutionContext.parasitic
also accomplishes the goal of keeping things single-threaded, and it doesn't require me to "run" the tasks submitted to it. Is there any advantage to usingSerialExecutionContext
overExecutionContext.parasitic
?The text was updated successfully, but these errors were encountered: