I have a suggestion: I would mention in the PODs that the sigalrm is used to establish the timeout. Almost every module that has a timeout uses a sigalrm to accomplish the task, and when they're used in combination, strange things happen. (Usually, the last assignment to $SIG{ALRM} overriders any former assignments.)

This would pose problems to those who use Net::Ping, for example, and less seasoned coders may not be aware of what is happening.

I'm going to keep this in my toolkit. I think it will see good use.

Glad you like it!

Yes I should make the fact that it uses $SIG{ALRM} explicit in the documentation. However note that TimeLimit always uses local $SIG{ALRM} which means that it gets reset to its previous value when it goes out of scope.

The answer to Net::Ping of course is that it should use TimeLimit too if it uses alarm(), or if you have some code that you think might be using alarm() &or $SIG{ALRM} and not resetting it then bracket it in a time_limit { } block and that will reset the alarm() & $SIG{ALRM} properly.

Ideally I should submit TimeLimit so CPAN so everyone who uses alarm() anywhere should use it instead!

An interesting module, and implemented well. As constructive critisim, there's two things I'd like to mention.

First, and simplest, you document a return value of undef on timeout but you actually return 0. This can trip people up so you might want to fix it.

Second, I think that, perhaps, you're handling nested time_limit()'s incorrectly (not that I really know what I mean by "correct"). Consider:

#!/usr/bin/perl -w

use TimeLimit;

$outter1 = time;
time_limit {
  $inner1 = time;
  time_limit { sleep 7 } 5;
  $inner2 = time;
} 3;
$outter2 = time;

$elapsed_outter = $outter2-$outter1;
$elapsed_inner  = $inner2-$inner1;
print "Seconds elapsed for outter limit: $elapsed_outter\n";
print "Seconds elapsed for inner limit:  $elapsed_inner\n";
[download]

The output of this test program is:

Seconds elapsed for outter limit: 5
Seconds elapsed for inner limit:  5
[download]

Whereas anyone looking at the outter time_limit() would think that it should return no more than 3s later. (Imagine the inner time_limit() call being burried in a called subroutine...)

Further, what if the code you expected to cause a timeout was after the inner time_limit() call? Because your code actually resets the alarm(), it could take even longer.

Of course, for most applications where you would want to time_limit() some code, you wouldn't really care if it takes a little bit longer to time out than you expected, so it shouldn't matter much. Also, I can't think of a very elegant solution that would handle such cases. I never did understand why they limited it to one alarm per process...

Well, I hope that at least gives you some ideas to work with. In fact, I think I might just have to look into writing a module that would offer a more robust replacement for alarm. :-) And again, congrats on a good module.

Happy coding.

bbfu
Seasons don't fear The Reaper.
Nor do the wind, the sun, and the rain.
We can be like they are.

Okay, I did a simple rewrite using my Alarm::Concurrent module. You can add ':OVERRIDE' just after 'setalarm' in the use line (line # 3) to have it take over $SIG{ALRM} if you like.

Let me know what you think. :-)

#!/usr/bin/perl -w

use Alarm::Concurrent qw( setalarm );

my $TIMELEVEL = 0;
sub timeout(&;$) {
  my $code = shift;
  my $time = shift || 30;

  my $dietext = "Timeout " . ++$TIMELEVEL . "\n";

  eval {
    local $SIG{__DIE__};
    setalarm($time, sub { die $dietext });
    $code->();
  };

  --$TIMELEVEL;

  if($@ eq $dietext) {
    return 0; # Timed out.
  } elsif($@ ne '') {
    die $@; # Propagate error upstream.
  }

  return 1; # Everything's ok.
}

timeout {
  timeout {
    sleep 10;
  } 3 or die "Inner timeout";
} 2 or die "Outter timeout";

print "Everything's ok.\n";
[download]

And the output is:

Outter timeout at ./testtimeout line 33.

bbfu
Seasons don't fear The Reaper.
Nor do the wind, the sun, and the rain.
We can be like they are.