in reply to mod_perl, prefork mpm and alarms

So, what's the problem? I didn't see it in your post. The main issue I'm aware of with alarm is that recent versions of perl (5.6+ I think) use "safe signal handling" which means you may not get the signal for a little bit. You can turn it off. There is some discussion of this problem in DBIx-Timeout.

Replies are listed 'Best First'.
Re^2: mod_perl, prefork mpm and alarms
by talexb (Chancellor) on Nov 29, 2006 at 19:19 UTC

    The problem is that the request goes to call Ghostscript and never comes back, possibly because of some incompatibility with alarm.

    I've since commented out all of the calls to alarm, and the problem remains.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      So it's not alarm then. If you call ghostscript the same way from a command-line perl program, does it also hang?

        To quote from my original post,

          In short, I am trying to call a potentially long running process (Ghostscript) that is wrapped in some code that sets an alarm, then does an eval to call Ghostscript. Either Ghostscript finishes, or the alarm triggers to catch a runaway page being rendered.

        What's happening is that the Apache process is dying about the time that the alarm is set. Dying is bad, in this context. OK, in any context.

        Running this code from the command line works fine, this I'm trying to understand why setting an alarm (my guess, based on output from strace) might be causing the problem. After commenting out all of the calls to alarm, I'm still seeing problems:

        Something still appears to be setting an alarm

        rt_sigaction(SIGALRM, {0x4044fc80, [], SA_RESTORER, 0x402b88f8}, {SIG_DFL}, 8) = 0

        that I presume is breaking Apache, even though I believe I'm running under the prefork MPM.

        Alex / talexb / Toronto

        "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds