[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Time constraint in Lua pattern functions
- From: Sean Conner <sean@...>
- Date: Mon, 14 Mar 2016 17:06:59 -0400
It was thus said that the Great Sean Conner once stated:
>
> Second solution: setrlimit(). We can limit the amount of CPU time we use.
> But this too, requires a signal handler, SIGXCPU or else if the process
> exceeds the CPU time, it's terminated. A library routine catching SIGXCPU
> might be less of an issue than catching SIGALARM but there's still a
> potential bug---setrlimit() is not an asynchronous-safe function, meaning
> it's not safe to call it from a signal handler, and we *have* to call it
> from the SIGXCPU signal handler or else our process goes bye-bye as it
> exceeded its allowable CPU limit.
Oh, some other issues with this solution. One, even *if* setrlimit() was
an aynchronous-safe function, we would need to track the previous setting
and up it each time the signal handler fired. We can keep doing this until
we hit the hard CPU limit and then ... well ... the process comes to an
abrupt end.
The second issue---setrlimit() sets the amount of time our process can run
on the CPU. It's *NOT* wall-clock time. Let's assume we set a limit of one
second of CPU time. The following C code:
char c;
read(0,&c,1);
can sit there forever [1] and never accumulate CPU time, assuming no input
is forthcoming. So depending upon what you are trying to timeout, this
method might not work that well either.
-spc (Man, it just gets uglier and uglier ... )
[1] Well, not technically "forever" as there will be a heat-death of the
universe to contend with, assuming the computer will survive our sun
dying but you get the idea.