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

config: linux: update description of PidsLimit #234

Merged
merged 1 commit into from
Nov 2, 2015
Merged

config: linux: update description of PidsLimit #234

merged 1 commit into from
Nov 2, 2015

Conversation

cyphar
Copy link
Member

@cyphar cyphar commented Oct 28, 2015

Fix a misleading comment for how PidsLimit works when given a limit of
0. A limit of 0 is identical to a limit of 1, and so there is no reason
to distinguish the two. Since the default value for integers in Go is 0,
it makes more sense to make the default value mean that there is no
limit.

Signed-off-by: Aleksa Sarai cyphar@cyphar.com (github: cyphar)

@cyphar
Copy link
Member Author

cyphar commented Oct 28, 2015

@vbatts
Copy link
Member

vbatts commented Oct 28, 2015

preciously LGTM

// Maximum number of PIDs. A value < 0 implies "no limit".
// Maximum number of PIDs. A value <= 0 implies "no limit".
// While a limit of 0 is technically valid, it is precisely identical to
// a limit of 1, so there is no distinction.
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you want both “≤ 0 means no limit” and “0 is the same as 1”? I'd expect either “≤ 0 means no limit and 0 is the same as -1” or “< 0 means no limit and 0 is the same as 1”. Or does 1 really mean “no limit”?

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh, sorry. What I meant was that "<= 0 means no limit within the spec, but a limit of 0 is identical to a limit of 1 in the PIDs controller". I guess I'm mixing specification and justification, based on the discussion in opencontainers/runc#58. I'll fix up the wording to only mention the actual specification and only leave the justification in the commit message.

Copy link
Contributor

Choose a reason for hiding this comment

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

On Wed, Oct 28, 2015 at 09:28:23AM -0700, Aleksa Sarai wrote:

Oh, sorry. What I meant was that "<= 0 means no limit within the
spec
, but a limit of 0 is identical to a limit of 1 in the PIDs
controller". I guess I'm mixing specification and justification,
based on the discussion in opencontainers/runc#58.

Oh, I see. In that case, my personal preference would be to just use
a uint pointer with “not set in the JSON means the runtime should
ignore” (see discussion in #233). But however this lands, any
semantic rules (like what values the runtime should ignore) should
also land in the runtime-config-linux.md docs where bundle authors
will find them.

Copy link
Member Author

Choose a reason for hiding this comment

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

@wking I agree (as I posted there) that #233 should in fact use pointers so that omitting and setting null have the same meaning (while also not requiring sentinel values). I'll revive this once we decide what we're going to do on #233.

Fix a misleading comment for how PidsLimit works when given a limit of
0. In the PIDs controller, a limit of 0 is identical to a limit of 1,
since it is not possible to impose a limit on 0 processes.

As such, it makes no sense to distinguish the two values, rather the
value 0 (which is also the default value of an integer in Go) should
instead indicate no limit (which is the default for all new PIDs
controllers).

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
@crosbymichael
Copy link
Member

LGTM

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.

4 participants