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
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 the ExecutionContext, those won't get run (and thus any Awaits will time out).
SerialExecutionContext is private, so I can't invoke the runNow method directly on there. The way I've hacked around this for now is by reflectively calling runNow after the Futures have been dispatched in afterAll:
Perhaps exposing something like that to be more conveniently called in afterAll would be nice? (Just making SerialExecutionContext 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 using SerialExecutionContext over ExecutionContext.parasitic?
The text was updated successfully, but these errors were encountered:
@LeifWSerialExecutionContext is just a simple form of default execution context, which was there before ExecutionContext.parasitic was introduced, and we still need to support older Scala version 2.10/2.11. I think you may try to override executionContext with ExecutionContext.parasitic or your custom SerialExecutionContext by just copying the original code and modify.
emanb29
pushed a commit
to thatdot/quine
that referenced
this issue
Mar 7, 2024
* 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
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: