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.

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?

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