Open tomtzook opened 3 years ago
Due to Action
s being stateful objects, there can only be one Future
at any given moment. The ExecutorService
API's Future
object is meant to be temporary, which makes since because the tasks are single-use and supposed to be state-less.
For Action
s, the Future
can and probably should be linked to the Action
object. This can be done by linking the Future
to an internal scheduler state.
Actions under
flashlib.core.scheduling
are tasks which a specific run flow which are executed by the scheduler. For a long time, that execution happened on the robot main thread, with the use of a synchronous scheduler implementation. With the possible introduction of multithreading into future implementations of scheduler, it is time to consider updating the actions API to expose async semantics.Although it is true that actions were sync in the sense that there was no multithreading involved; they are not actually sync, as in a call to start did not block until the action finished. Instead, the action was left to execute whenever after started.
Due to being async it is usually necessary to provide some way to interact with actions when needed. This does exist with some methods in
Scheduler
, likeScheduler.cancel
and such. This is severely limiting however, as exposing certain additional functionalities will complicate the implementation ofScheduler
, especially in a multithreaded environment. In addition, it either forces user to interact with theScheduler
directly at times, which is unwanted:or adds more methods to
Action
/ActionBase
to hid that requirement, which fills the interface/class with wrapping code.Thus allowing:
Further more. this kind of API is not desirable since it is not immutable for
Action
, as it can only be used if the action is running. And this could be amplified with different kinds of information thatAction
could be required to supply - such as a return value.Proposal
With inspiration from Java's
ExecutorService
API, I propose to use aFuture
-like object (or actually useFuture
) to facilitate aysnc semantics:And usage:
Since
Future
is a contained object representing a singleAction
, implementations ofScheduler
should be able to find it easy to integrate it.With the new API,
Future
can be packed with methods to query information about the execution ofAction
without clattering theScheduler
andAction
interfaces.This also opens the way for
Actions
to produce results (likeCallable
) and allows users to handle exceptions and perhaps more.java.util.concurrent.Future
vs CustomFuture
After seeing the advantages of using a
Future
-like interface with theActions
API; we are left with choosing whether or not to use thejava.util.concurrent.Future
provided with theExecutorService
API from Java.There are a number of advantages for using it:
CompletableFuture
) already exist, so less code to write.However, there are some disadvantages:
Future
, so adding custom methods might be problematic.All in all, it's hard to say which to choose. So as of yet, it is undecided.