Skip to content
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

Open
LeifW opened this issue Mar 2, 2024 · 1 comment
Open

Execute tasks on SerialExecutionContext outside of a test #2314

LeifW opened this issue Mar 2, 2024 · 1 comment

Comments

@LeifW
Copy link

LeifW commented Mar 2, 2024

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:

val runNow = PrivateMethod[Unit](Symbol("runNow"))
executionContext invokePrivate runNow(Future.successful(Succeeded))

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?

@cheeseng
Copy link
Contributor

cheeseng commented Mar 5, 2024

@LeifW SerialExecutionContext 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants