Re: setrlimit() extension suggestion

On Mon, 21 Apr 2008 04:58:53 -0700 (PDT) David Schwartz <davids@xxxxxxxxxxxxx> wrote:
| On Apr 20, 10:43 pm, phil-news-nos...@xxxxxxxx wrote:
|
|> I'd like to suggest an extension to setrlimit() and getrlimit(). The resource
|> symbol would be RLIMIT_TIME (or RLIMIT_LINUX_TIME to designate an extension in
|> case a future POSIX change uses RLIMIT_TIME in an incompatible way). What it
|> should do is set a limit on "wallclock" time.
|
| I can't think of a use for it.

I'd like to suggest that all the features in Linux that you can't think of
a use for be immediately removed.

I had a use for it yesterday. I ended up using the "timelimit" program in
the netpipes package.


|> Unreliable means exist now. One of them is a parent process that keeps time
|> and kills the child. But a child could "run away" fairly easily (fork and
|> change process group). A hard RLIMIT_TIME would be inescapable.
|
| I don't see how that would be useful. You would face an insoluable
| "three bears" problem. Minutes are too low for long-lived working
| processes, but seconds are too long for fork bombs.

Uh ... you can specify whatever time limit you want. Minutes and seconds are
just a resolution. If 15 seconds is just right, then use that. If you think
we need a finer resolution than 1 second, what is in your mind? Milliseconds?


| If that's the job, the proposed RLIMIT_TIME is the wrong tool.

What do you think is the right tool to make sure a process be run for no more
than 15 seconds wallclock time (it doesn't use much CPU time)?

--
|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) |
.