-
Notifications
You must be signed in to change notification settings - Fork 47
Hv issue719 job manager threaded job start #736
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
Conversation
|
@soxofaan maybe good to rediscuss from this point (local unit tests are passing) |
soxofaan
left a comment
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.
some quick notes
|
by the way, I don't think you had to create a new PR, you just could have continued on #730 by pushing to its feature branch (we now have three open PRs for this feature I think, which gets a bit messy) |
|
worked on your initial comments @soxofaan currently checking why some unit tests are not passing |
indeed, that problem has been fixed on master by now |
|
One issue I still see now and want to resolve is that currently launching jobs (to queue them for start) is still tied in to the backend load. This means than when running at full capacity you will not already 'precreate jobs' which can instantly start running |
I'm not sure that pre-creating jobs instead of on the fly like we currently do will make that big of a difference as the time to create a job is usually negligible compared to the required time to start a job. Or do you experience different timings? |
is not necessary and eliminates `job_db.read()` which is not part of JobDatabaseInterface
and remove old "sleep" reference
to improve signal/noise ratio of PR (using darker and ruff)
using `ruff format`, `ruff check --fix --select F401,I001` and `isort`
- split `Task` hierarchy for better separation of concerns - more tests for some basic classes - clean up unused fixtures from tests - DummyBackend: add setup_job_start_failure
- support waiting directly in process_futures - switch to DummyBackend - use more dummy tasks TestJobManagerWorkerThreadPool to simplify setup
is not necessary and eliminates `job_db.read()` which is not part of JobDatabaseInterface
and remove old "sleep" reference
|
FYI: as this is a very long running PR with messy history, I tried to rebase the feature branch of this PR to clean it up a bit (e.g. commit squashing) to improve the signal-noise ratio and created PR #806 . The diff is practically identical to #736 (except for one empty line). The discussion can stay here (#736), but #806 will be merged in the end |
to improve signal/noise ratio of PR (using darker and ruff)
using `ruff format`, `ruff check --fix --select F401,I001` and `isort`
- split `Task` hierarchy for better separation of concerns - more tests for some basic classes - clean up unused fixtures from tests - DummyBackend: add setup_job_start_failure
- support waiting directly in process_futures - switch to DummyBackend - use more dummy tasks TestJobManagerWorkerThreadPool to simplify setup
is not necessary and eliminates `job_db.read()` which is not part of JobDatabaseInterface
and remove old "sleep" reference
No description provided.