in reply to Re: Re: Re: Re: Re: Re: Upgrading Perl in production environment
in thread Upgrading Perl in production environment

I'm using "trading systems" as an example

unfortunately, even the gethostbyaddr_r series of c functions can hang as well. depending on the load of the box and a dozen other reasons, the response from the name server (or whatever else) may not actually be received.

If a signal comes in and perl core dumps with half finished work... that's fine, there are clean up routines that identify where the breakage occurred and repair whatever was broken.

Using unsafe signals IS okay, IF the proper precautions are taken for recovery and continuing where it broke.

What I'm saying is that unsafe signals do have their uses and should never be removed from perl entirely.. Perhaps perl should be fixed to handle them better?

  • Comment on Re: Re: Re: Re: Re: Re: Re: Upgrading Perl in production environment

Replies are listed 'Best First'.
Unsafe signals are called "Unsafe" for a reason, you know
by chip (Curate) on Mar 19, 2004 at 18:04 UTC
    You just don't get it.

    It is never safe to use unsafe signals. You don't know what will happen. You can't be sure that when things go wrong you'll get a SEGV and program death, allowing for cleanup. You don't know what will happen. Nobody knows. Nobody can predict what an unsafe signal will cause. Nobody! That's what makes them "unsafe"!

    (What frame of mind is required for someone to think that it's safe to use a feature called "unsafe signals"? I can't fathom it, I just can't.)

        -- Chip Salzenberg, Free-Floating Agent of Chaos

[reply]
      Actually I do understand your point of view... and agree with you for the most part.

      even if the process goes into lala land, a separate process will kill it, start a new process which will examine what was done, undo whatever was 'messed up', and continue with the task. The overall effect would be no worse than performing kill -SIGKILL (-9).

      However, if I just wrote a routine to restart the system call without any other failsafe in place, then that would be bad and irresponsible.

      For most tasks, the unsafe signals are undesirable.. on certain tasks, they are unavoidable and necessary. The fact that they are unsafe is a failure of the Perl engine... so we have to make do, for now, with what we have and build contingency plans for using the unsafe signals.

[reply]
        What you so blithely describe as "lala land" is undefined behavior. It could be anything, including something incredibly destructive. It could be jumping into &main::destroy_all_monsters. It could be calling system("rm -rf $HOME"). It could be anything. (Get the point yet? No?)

        That is why it unsafe signal handling is called "unsafe", and that is why there is NO situation in this particular universe where it is acceptable. At all. Ever. No exceptions.

        Got it? No? Oh well. I'm giving up on educating you. But I was serious about wanting to know where that financial program is that uses unsafe signals. I really don't my money there. I'm totally serious about that.

            -- Chip Salzenberg, Free-Floating Agent of Chaos

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom