in reply to Safety of using alarm

Prior to perl 5.8.0, signals in Perl are unsafe. This is because signals are handled immediately if they arrive, regardless whether the internals of perl are in a consistent state or not. Furthermore, lots of function (including many of the implicite functions, like looking at a variable) in Perl aren't reentrant safe.

Abigail

Replies are listed 'Best First'.
Re: Re: Safety of using alarm
by delirium (Chaplain) on Mar 11, 2004 at 13:17 UTC
    Thanks.

    Are you aware of any alternatives that are safer with 5.6.0? What type of problems might occur with the way I have things set up now? Segfaults out of the blue?

[reply]
      Are you aware of any alternatives that are safer with 5.6.0?
      Yes. Use something else than Perl.
      What type of problems might occur with the way I have things set up now? Segfaults out of the blue?
      Anything can happen. Segfaults. Data corruption. Pink monkeys flying out your managers ears. Don't think that unsafe signals means their damage is contained in a neatly defined box.

      In 5.6.0 signals are UNSAFE, and that's non-negotiable.

      Abigail

[reply]
        Fair enough.

        After searching around, I was not able to find any examples of actual problems caused by alarms (that is, no problems that did not involve Apache).

        My testing shows no problems when alarm is called with my script, so I'm going to assume my likelihood of running into trouble is right up there with the spontaneous appearance of monkeys.

        However, the non-Perl route is possible and trivial, so I have good enough reason to code a backup solution using Korn Shell's alarm function.

        Thanks for the input.

[reply]

In Section Seekers of Perl Wisdom