-
Notifications
You must be signed in to change notification settings - Fork 444
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
feat: IO.TaskState
#4097
feat: IO.TaskState
#4097
Conversation
Mathlib CI status (docs):
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using Promise
we could add a test case for at least waiting and finished
inductive TaskState | ||
/-- | ||
The `Task` is waiting for dependencies to complete or | ||
sitting in the task manager queue waiting for a thread to run on. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or waiting for Promise.resolve
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The docs have been updated. However, after adding the test, I discovered that it is, in fact, the running
state that includes the promised C state. Unfortunately, the C implementation does not provide a way to distinguish between a running Task
and a waiting Promise.result
(they both have null closures). Thus, I added this info to running
.
Adds `IO.getTaskState` which returns the state of a `Task` in the Lean runtime's task manager. The `TaskState` inductive has 3 constructors: `waiting`, `running`, and `finished`. The `waiting` constructor encompasses the waiting and queued states within the C task object documentation, because the task object does not provide a low cost way to distinguish these different forms of waiting. Furthermore, it seems unlikely for consumers to wish to distinguish between these internal states. The `running` constructor encompasses both the running and promised states in C docs. While not ideal, the C implementation does not provide a way to distinguish between a running `Task` and a waiting `Promise.result` (they both have null closures). (cherry picked from commit 25e94f9)
Adds `IO.getTaskState` which returns the state of a `Task` in the Lean runtime's task manager. The `TaskState` inductive has 3 constructors: `waiting`, `running`, and `finished`. The `waiting` constructor encompasses the waiting and queued states within the C task object documentation, because the task object does not provide a low cost way to distinguish these different forms of waiting. Furthermore, it seems unlikely for consumers to wish to distinguish between these internal states. The `running` constructor encompasses both the running and promised states in C docs. While not ideal, the C implementation does not provide a way to distinguish between a running `Task` and a waiting `Promise.result` (they both have null closures). (cherry picked from commit 25e94f9)
Adds `IO.getTaskState` which returns the state of a `Task` in the Lean runtime's task manager. The `TaskState` inductive has 3 constructors: `waiting`, `running`, and `finished`. The `waiting` constructor encompasses the waiting and queued states within the C task object documentation, because the task object does not provide a low cost way to distinguish these different forms of waiting. Furthermore, it seems unlikely for consumers to wish to distinguish between these internal states. The `running` constructor encompasses both the running and promised states in C docs. While not ideal, the C implementation does not provide a way to distinguish between a running `Task` and a waiting `Promise.result` (they both have null closures). (cherry picked from commit 25e94f9)
Adds
IO.getTaskState
which returns the state of aTask
in the Lean runtime's task manager. TheTaskState
inductive has 3 constructors:waiting
,running
, andfinished
. Thewaiting
constructor encompasses the waiting and queued states within the C task object documentation, because the task object does not provide a low cost way to distinguish these different forms of waiting. Furthermore, it seems unlikely for consumers to wish to distinguish between these internal states. Therunning
constructor encompasses both the running and promised states in C docs. While not ideal, the C implementation does not provide a way to distinguish between a runningTask
and a waitingPromise.result
(they both have null closures).