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

WIP: Add JobManager #4287

Draft
wants to merge 2 commits into
base: series/3.x
Choose a base branch
from

Conversation

BalmungSan
Copy link
Contributor

Implements the JobManager idea proposed in #1345


Roadmap

  • Define the API.
  • Implement it.
  • Add tests.
  • Add docs.

* Creates and launches the given `Job` in the background. If another Job with the same id was
* already running, it will be cancelled before starting this one.
*/
def startJob(id: Id, job: Resource[F, JobManager.Job[F, S]]): F[Unit]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On one had, I like the idea of users being able to use their own Ids.
On the other, I think most users would benefit from a default using automatically generated UUIDs.

Should we provide such default in some way?

Comment on lines +34 to +38
/**
* Gets the status of the `Job` associated with the given `id`. If `id` doesn't exists or the
* `Job` already finished then the returned value will be a `None`.
*/
def getJobStatus(id: Id): F[Option[S]]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I somewhat dislike the idea that both bad id and already finished return in a None.
But, otherwise, the map will grow indefinitely.

Any ideas?

Comment on lines +40 to +44
/**
* Signals cancellation of the `Job` associated with the given `id`, and waits for its
* completion.
*/
def cancelJob(id: Id): F[Unit]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we provide a cacelAndForget variant where we don't wait on cancellation?

Comment on lines +52 to +63
trait Job[F[_], S] {

/**
* Starts the logic of this `Job`.
*/
def run: F[Unit]

/**
* Gets the status of this `Job`.
*/
def getStatus: F[S]
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Users would then implement this trait for their own Jobs.

}
}

supervisor.supervise(runJob).void
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't wait for the Job to start before returning to the user.
But, that means there is a brief delay between starting the Job and users being able to query its status.

cancel = fiber.cancel
).some
)
.flatMap(_.traverse_(_.cancel)) >>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case the same id was already used, we cancel the previous Job.

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

Successfully merging this pull request may close these issues.

1 participant