alarm sounds like the right approach here. So you need to show your code (reduced to the relevant part) here, otherwise we can't know what's wrong with it.

See also: How (Not) To Ask A Question

#!/usr/bin/perl

eval {

   local %SIG;
   $SIG{ALRM}=
     sub{ die "timeout reached, after 20 seconds!\n"; };
   alarm 20;
   print "sleeping for 60 seconds\n";
   #sleep 60; # This is where to put your code, between the alarms
   $x=<stdin>;
   alarm 0;
};

alarm 0;

if($@) { print "Error: $@\n"; }

exit(0);
[download]

Here we should enter some input, but my requirement is if the input is not enetered in 20 sec, it should come out of the program(Exit the program).

but my requirement is if the input is not enetered in 20 sec, it should come out of the program(Exit the program).

And that's what the program does (as far as I can tell; but hard to tell, since it is formatted so badly here). Which is why I wonder what your actual question is.

#!/usr/bin/perl

use Modern::Perl;
my $sec = 0;

while($$) {
        # Do something. May want to fork a child to do the work.
        say "running...[$sec]";

        exit if $sec == 600;
        sleep 1;
        $sec++;
}
[download]

Bad idea, unless your perl port lacks a working alarm. alarm works without active waiting, and sleep 1 does not always sleep exactly one second.

Quoting perlfunc:

On some older systems, it may sleep up to a full second less than what you requested, depending on how it counts seconds. Most modern systems always sleep the full amount. They may appear to sleep longer than that, however, because your process might not be scheduled right away in a busy multitasking system.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

1. alarm works without active waiting,

   Since the advent of SAFE_SIGNALS; alarm won't interrupt long running opcodes.

   And the cpu requirement of the "active waiting" -- waking 1 per second:

   C:\test>perl -E"sleep 1 for 1..120; say join ' ', times"
   0 0.015 0 0
   [download]

   0.015/120 = 0.0125% cpu usage; means that it would require 8000 of these actively waiting tasks to even register a blip on a cpu usage graph.

2. sleep 1 does not always sleep exactly one second.

   On modern OSs, the differences are tiny -- essentially the time taken between the 1 second elapsing and the process getting its next time-slice:

   C:\test>perl -MTime::HiRes=time -E"$t=time; sleep 1 for 1 .. 10*60; pr
   +int (time()-$t) - 10*60"
   601.386687040329
   [download]

   601.386687040329 - 600 / 600 = 0.002311145067215. A couple of milliseconds

   Which means that after 10 minutes of waiting, those tiny differences will have accumulated such that you've ended up giving the user a whole extra second in which to respond. Big deal.

   But the kicker is: alarm will suffer from the essentially the same delays and inaccuracies! Once the system timer times out and sets the flag in the kernel thread structure; it still won't run until it filters its way to the top of the schedulers list of run-eligible threads.

Re-reading the post to which you responded and the OP; the former is almost certainly not a solution to the latter -- but definitely not because of the reasons you cite. They are just sweating the small stuff whilst ignoring the bigger picture.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.