Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Re: Re: Re: Re: Upgrading Perl in production environment

by chip (Curate)
on Mar 19, 2004 at 17:39 UTC ( #338076=note: print w/replies, xml ) Need Help??

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

You would use unsafe signals in a trading system?

Have you gone totally mad?

Unsafe signals can hit at any time, and leave the Perl internals in an unknown, unsafe, unusable state. Then the unsafe signal handler proceeds to execute Perl code using those internals! A trading system is exactly the kind of high-stakes deployment where everything must be safe!

If you want a fast restart, then you should have a watchdog process outside the target, which can kill it (with SIGKILL if necessary) and restart it. That way you're getting a fast response without putting yourself at risk for a big financial bath.

    -- Chip Salzenberg, Free-Floating Agent of Chaos

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

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Upgrading Perl in production environment
by jfroebe (Parson) on Mar 19, 2004 at 17:47 UTC
    I guess I should have been more clear... the scripts for maintenance mostly and information gathering not for the trading itself.

    The maintenance windows tend to be very short. If a scripts hangs on say a gethostbyaddr() then abort the call, and retry the gethostbyaddr().. if the script goes down, start the entire job over.

    If the process normally takes 10 mins and if the script hangs on 9 mins 59seconds, then I would rather risk restarting that hanging operation then having to start all over again... if it goes down, then I will start it all over again.

      Anything financial is almost by definition high value and should never involve the use of unsafe signals. You can call it "maintenance and information gathering" but that doesn't change anything.

      There are libraries for asynchronous DNS lookup. There are fork and pipes. There are lots of things you can do. If any of them involve unsafe signals ... well, let's just say I'd like to know where you wrote such a system so I can make sure not to invest my money there.

          -- Chip Salzenberg, Free-Floating Agent of Chaos

        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?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://338076]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (7)
As of 2018-05-24 18:20 GMT
Find Nodes?
    Voting Booth?