Refactor scala.scalanative.runtime.ExecutionContext
#3144
Conversation
WojciechMazur
changed the title
scala.concurrent.ExecutionContext scala.scalanative.runtime.ExecutionContext
| // The proxy methods here are defined to allow integrating projects | ||
| // to interact with our private execution context without leaking the abstraction | ||
|
|
||
| /** Checks if there is any scheduled runnable which can be executed */ | ||
| private[runtime] def hasNext: Boolean = QueueExecutionContext.hasNext | ||
|
|
||
| /** Exuecute next available runnable in the queue. No-op if the queue is empty | ||
| */ | ||
| private[runtime] def runNext(): Unit = QueueExecutionContext.runNext() | ||
|
|
||
| /** Returns the number of currently scheduled tasks */ | ||
| private[runtime] def scheduled: Int = QueueExecutionContext.scheduled | ||
|
|
||
| /** Execute all the tasks in the queue until there is none left */ | ||
| private[runtime] def loop(): Unit = QueueExecutionContext.loop() |
There was a problem hiding this comment.
I'm glad we are considering these APIs, but maybe can this happen in a separate PR? I think this deserves a discussion. Cats Effect might also benefit from this, but we have also been successful without it—it is not a blocker.
In Scala Contributors1 we discussed adding some new APIs to Scala standard library that will better support event loops. For example a Scheduler API. This appears to have support from Scala Center, and Cats Effect team is also motivated for this change.
If those changes land in Scala 2.13 standard library, then it means single-thread Scala Native will be able to support tasks and timers out-of-the-box. So we should be careful to design this API so that we can make those changes without breaking backwards-compatibility.
Footnotes
There was a problem hiding this comment.
Oh, that's a good point. In such a case, I'll be putting this on hold, and I would use the old API instead in further integration of multithreading.
There was a problem hiding this comment.
I've reverted all the changes that expose new methods, I'll create a seperate PR with API extension
WojciechMazur
force-pushed
the
refactor/multithread-native-execution-context
branch
2 times, most recently
from
85f8302
to
32896c0
Compare
… the API to allow for 3rd party integration. Deprecated `runtime` package `loop` accessor
WojciechMazur
force-pushed
the
refactor/multithread-native-execution-context
branch
from
32896c0
to
7cac7ec
Compare
…usinng dedicated onShutdown method
scala.scalanative.runtime.ExecutionContextNativeExecutionContextto match Scala.js naming conventions (JsExecutionContext)globalaccessor, usequeueinsteadQueueExecutionContextbased on @lolgab work in Add loopRunOnce to runtime and ExecutionContext #1852hasNext,sheduled,runNextjunit-asyncandtest-interfacemodules to use new interfacescala.scalanative.runtime.loopBased on that change we would provide the
scala.concurrent.ExecutionContextchanges allowing to use real concurrent execution context in multithreading mode