eval EXPR with maximum execution time?

[alx__21]

Hi,

I'm looking for something that is like eval in that it can compile and
run code from strings, but will quit after a maximum given time.

The benchmark module tool "timethis" is very close, but it can only
ever specify a minimum time to iterate the given code. What I want is
code that iterates ONCE, breaking at a maximum time that I can specify
(if it runs that long).

If anybody knows of a function to do this I would appreciate it. I
would rather not have to start digging around in the source for
timethis to create my own.

Thanks.

 

[Joost Diepenmaat]

Hi,

I'm looking for something that is like eval in that it can compile and
run code from strings, but will quit after a maximum given time.

The benchmark module tool "timethis" is very close, but it can only
ever specify a minimum time to iterate the given code. What I want is
code that iterates ONCE, breaking at a maximum time that I can specify
(if it runs that long).

If anybody knows of a function to do this I would appreciate it. I
would rather not have to start digging around in the source for
timethis to create my own.

Thanks.

See perldoc -f alarm, but note that your code may still block on IO, as
far as I know, if your perl was build with "safe signals" - the default
for a few years now.

Joost.

 

[Joost Diepenmaat]

See perldoc -f alarm, but note that your code may still block on IO, as
far as I know, if your perl was build with "safe signals" - the default
for a few years now.

Joost.

For a possibly more robust (or at least, more certain way of stopping
processing) you could fork() the offending process and kill() it from
the parent if it doesn't stop after a sleep().

If you want to get any useful data back from the fork()ed child process,
you need some kind of IPC. See the perlopen and perlipc man pages.

Joost.

 

[Ben Morrow]

Using POSIX::SigAction it is possible to install an unsafe handler for
SIGALARM, which will allow you to break out of IO. Of course, all the
traditional caveats about unsafe signals then apply: it would be best to
do nothing more in the sighandler than die to break out of the eval.

For a possibly more robust (or at least, more certain way of stopping
processing) you could fork() the offending process and kill() it from
the parent if it doesn't stop after a sleep().

If you want to get any useful data back from the fork()ed child process,
you need some kind of IPC. See the perlopen and perlipc man pages.

If you make the child the watchdog instead, there's no need for this. It
also makes it easier to clean up after a successful completion. Of
course, it makes it slightly *harder* to clean up after an unsuccessful
completion: you're pretty much back to signalling the parent, catching
that signal unsafely, and breaking out of the eval. See above . If
you're not using alarm for anything else (on many systems, sleep uses
alarm internally) it is probably the best solution.

Ben

 

[alx__21]

Thank you!
As I'm not doing any IO inside the eval (just a simple return at the
end), I think that alarm will work well.

 

[xhoster]

See perldoc -f alarm, but note that your code may still block on IO, as
far as I know, if your perl was build with "safe signals" - the default
for a few years now.

I don't think that that would be a problem for IO. OS-level IO calls
will get interrupted, and perl will then either not resume them (having the
Perl-level call set $! and return failure) or perl will execute the sig
handler and then try to resume the call. In either case, a sig handler
that dies should break out of the eval promptly. It is things
that spent a long time at the perl level (as opposed to the system level,
or the Perl level), like sorts and large regex, that have the problem with
safe signals.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

 

[alx__21]

I don't think that that would be a problem for IO. OS-level IO calls

will get interrupted, and perl will then either not resume them (having the
Perl-level call set $! and return failure) or perl will execute the sig
handler and then try to resume the call. In either case, a sig handler
that dies should break out of the eval promptly. It is things
that spent a long time at the perl level (as opposed to the system level,
or the Perl level), like sorts and large regex, that have the problem with
safe signals.

Xho

How much of a problem? For my application a second either way won't
matter much, but it definitely needs to be stopped at some point
(infinite loop issues).

 

[alx__21]

I don't think that that would be a problem for IO. OS-level IO calls

will get interrupted, and perl will then either not resume them (having the
Perl-level call set $! and return failure) or perl will execute the sig
handler and then try to resume the call. In either case, a sig handler
that dies should break out of the eval promptly. It is things
that spent a long time at the perl level (as opposed to the system level,
or the Perl level), like sorts and large regex, that have the problem with
safe signals.

Xho

How much of a problem? For my application a second either way won't
matter much, but it definitely needs to be stopped at some point
(infinite loop issues).

 

[alx__21]

I don't think that that would be a problem for IO. OS-level IO calls

will get interrupted, and perl will then either not resume them (having the
Perl-level call set $! and return failure) or perl will execute the sig
handler and then try to resume the call. In either case, a sig handler
that dies should break out of the eval promptly. It is things
that spent a long time at the perl level (as opposed to the system level,
or the Perl level), like sorts and large regex, that have the problem with
safe signals.

Xho

How much of a problem? For my application a second either way won't
matter much, but it definitely needs to be stopped at some point
(infinite loop issues).

 

[alx__21]

I don't think that that would be a problem for IO. OS-level IO calls

will get interrupted, and perl will then either not resume them (having the
Perl-level call set $! and return failure) or perl will execute the sig
handler and then try to resume the call. In either case, a sig handler
that dies should break out of the eval promptly. It is things
that spent a long time at the perl level (as opposed to the system level,
or the Perl level), like sorts and large regex, that have the problem with
safe signals.

Xho

How much of a problem? For my application a second either way won't
matter much, but it definitely needs to be stopped at some point
(infinite loop issues).

 

[alx__21]

heh . . . my refreshing to see if anybody responded caused a new
message to be tacked on each time -- new post data to the server.
Sorry. Poor design, Google.

 

[xhoster]

How much of a problem? For my application a second either way won't
matter much, but it definitely needs to be stopped at some point
(infinite loop issues).

I don't think perl is likely to have any infinite loops in its internals.
Presumably the infinite loop is in your Perl code, not in the C code which
implements perl. So an alarm with a handler that dies should work.

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

 

[comp.llang.perl.moderated]

How much of a problem? For my application a second either way won't
matter much, but it definitely needs to be stopped at some point
(infinite loop issues).

Maybe Xho or someone else is more informed on this issue but itseems
to me that there shouldn't be a problem. An alarm will still be
delivered even if the opcode sequence is lengthy. Maybe the delivery
will occur a bit after the alarm. The exact timing of safe signals is
still murky to me. There's a many-to-one ratio of opcodes to actual
high level code so I suspect the alarm signal is unlikely to be
delayed excessively. Dunno for sure. Still only the first of multiple
same-type signals occurring during a delay is delivered (others are
lost). I could see that being problematic in the case of child signals
for instance but not an alarm. Any other potential problems...?