-
Notifications
You must be signed in to change notification settings - Fork 257
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
Correctly set silo field when opening job object #1437
Conversation
a6700d3
to
66618c5
Compare
Rebased to pickup CI fix for mingw |
@kevpar ptal when you get a chance again |
We don't set the silo field on Open of an existing job object today. This is useful if once opening a job we want to bind a file that only that silo can see as it relies on atomically checking the `silo` u32 field to determine if we can carry out the operation. The manner in which we check if the job is a silo is by using a new jobobject information class with QueryInformationJobObject that fails unless the job is a silo. Signed-off-by: Daniel Canter <dcanter@microsoft.com>
Change to isJobSilo from pointer receiver method as calling a method on an object we made in the same function is a bit odd. Signed-off-by: Daniel Canter <dcanter@microsoft.com>
As a side note, it seems weird to have |
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.
LGTM pending CI
Agree, especially as it does nothing for Open |
* Correctly set silo field when opening job object We don't set the silo field on Open of an existing job object today. This is useful if once opening a job we want to bind a file that only that silo can see as it relies on atomically checking the `silo` u32 field to determine if we can carry out the operation. The manner in which we check if the job is a silo is by using a new jobobject information class with QueryInformationJobObject that fails unless the job is a silo. Signed-off-by: Daniel Canter <dcanter@microsoft.com>
* Correctly set silo field when opening job object We don't set the silo field on Open of an existing job object today. This is useful if once opening a job we want to bind a file that only that silo can see as it relies on atomically checking the `silo` u32 field to determine if we can carry out the operation. The manner in which we check if the job is a silo is by using a new jobobject information class with QueryInformationJobObject that fails unless the job is a silo. Signed-off-by: Daniel Canter <dcanter@microsoft.com>
We don't set the silo field on Open of an existing job object today.
This is useful if once opening a job we want to bind a file that only
that silo can see as it relies on atomically checking the
silo
u32field to determine if we can carry out the operation.
The manner in which we check if the job is a silo is by using a new
jobobject information class with QueryInformationJobObject that fails
unless the job is a silo.