Re: setrlimit() extension suggestion
- From: phil-news-nospam@xxxxxxxx
- Date: 29 Apr 2008 18:24:28 GMT
On Mon, 28 Apr 2008 04:32:10 -0700 (PDT) David Schwartz <davids@xxxxxxxxxxxxx> wrote:
| On Apr 27, 2:14 pm, phil-news-nos...@xxxxxxxx wrote:
|
|> If you can understand the effect as described by the suggestion, maybe you can
|> suggest a way to do it that does not involve a kernel change. I won't think
|> less of you if you cannot, because I cannot think of such a way.
|
| It's impossible to solve a problem if you don't say what the problem
| is. All you've told me is how you propose to solve the problem, and
| then you've asked me how I would solve it. Well, I don't know. The
| reason I don't know is because I don't know what the problem is.
The problem is: how to make sure a process, including all its children,
even if any of these processes change controlling TTY and/or process group,
shall not exceed a specified resource limit, where that resource is a
wallclock time frame.
|> If you cannot understand the effect as described, then I don't see any purpose
|> in continuing the discussion with you. But I highly doubt this is the issue.
|> I suspect it is more likely you do work more at the system level and less at
|> the application level and have simply never encounted the need because of the
|> lesser exposure. You and I frequently do not see things the same way, and
|> this might be at least one of the reasons why.
|
| I understand the effect, I just don't understand the reason you would
| want that effect. It seems to me that such an effect would be useless
| because of the three bears problem I already explained. Settings of,
| say, 30 seconds would be too long because a process running away for
| 30 seconds would make an interactive machine useless. Settings of,
| say, 4 minutes would be too short because it would be too hard to make
| long-running processes. These two settings overlap in the wrong way.
I think maybe you don't understand the effect. I conclude this because your
of your assertion that setting a limit of 30 seconds would "make an interactive
machine useless". You seem to be assuming that the setting would be applied to
every process running in the entire system. I've never suggsted such a thing.
And setrlimit() doesn't do such a thing. What setrlimit() does is set the limit
value for the current process (limited to only the soft limit if the process
calling setrlimit() does not have root permission). Your discussion about a
4 minute limit seems to also indicate a mis-understanding of the effect. The
settings would not overlap. The settings would not be applied universally to
all processes. The settings would only apply to the specific processes (and
their children inherit it) that call setrlimit() to set it.
I'll describe the effect in more detail so that maybe you can understand it
correctly.
For each process, a (new) resource limit shall exist with a soft and hard
value. This resource limit specified in the members of struct rlimit shall
be the number of seconds from the current time afterwhich the process shall
not be allowed to continue to execute. An implementation shall behave in
such a manner that is equivalent to an implementation that stores an internal
value of an absolute wallclock time beyond what the process shall not be
allowed to continue to execute. When a process forks a child, the child
inherits the same wallclock time limit as the parent such that of both try
to continue to run, both shall not be allowed to continue beyond the same
point in time, unless that limit is changed. Like other resources used in
setrlimit(), the soft limit is not permitted to exceed the hard limit, and
only a process with root permissions may set the hard limit. If setrlimit()
has never been called for this resource, or if setrlimit() is called with
values of RLIM_INFINITY, then this resource shall not cause a process to be
stopped.
My interest is whether or not any issues in the design of the kernel would
make an implementation of the above feature/effect difficult or impossible.
I would think it should be entirely possible. Somewhere, other resources
are checked to be sure a process does not exceed them. This would be one
more resource to check. Checking it would be a matter of comparing the
internally stored wallclock limits (derived from adding the limit values
given in struct rlimit with the wallclock time when setrlimit() is called)
with the current wallclock value.
What signal to send a process that exceeds the soft limit, but has not yet
exceeded the hard limit, I have not specified. Suggestions? For a process
reaching the hard limit, RLIMIT_CPU uses SIGKILL and that seems appropriate
for this proposed resource. But I'm not so sure that SIGXCPU would be for
the soft limit, even though that is what is used for RLIMIT_CPU.
| So I don't understand why you would ever want the effect this setting
| gives you. There may or may not be other good ways to get this same
| effect, but what I don't see is why it matters.
You don't need to understand the why. You can choose to dismiss the idea
because you can't see any reason _you_ would want to use it. Maybe someone
else won't.
--
|WARNING: Due to extreme spam, I no longer see any articles originating from |
| Google Groups. If you want your postings to be seen by more readers |
| you will need to find a different place to post on Usenet. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
.
- Follow-Ups:
- Re: setrlimit() extension suggestion
- From: David Schwartz
- Re: setrlimit() extension suggestion
- References:
- setrlimit() extension suggestion
- From: phil-news-nospam
- Re: setrlimit() extension suggestion
- From: David Schwartz
- Re: setrlimit() extension suggestion
- From: phil-news-nospam
- Re: setrlimit() extension suggestion
- From: David Schwartz
- Re: setrlimit() extension suggestion
- From: phil-news-nospam
- Re: setrlimit() extension suggestion
- From: David Schwartz
- setrlimit() extension suggestion
- Prev by Date: Re: write
- Next by Date: Re: write
- Previous by thread: Re: setrlimit() extension suggestion
- Next by thread: Re: setrlimit() extension suggestion
- Index(es):
Relevant Pages
|