I remember that there was a good description in the Camel book (16: Signals - Timing out Slow Operations). Since Perl tries to recover from interrupted system calls, a eval/die-construct was necessary to handle this situation properly. A similar description can be found in the perlipc-doc after the second occurrence of longjmp.

You've probably done that, but if not then you should consider resetting the alarm after successful completion (alarm(0);).

Update: In the Camel book example, the alarm was cleared again after the eval-block to cope with a race condition when the signal occurred after a successful IO operation but before resetting the alarm within the same eval block. I am not sure if this is still an issue with modern kernels.