Re: Re: Unsafe signals are called "Unsafe" for a reason, you know

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

Comment on Re: Re: Unsafe signals are called "Unsafe" for a reason, you know Select or Download Code

Replies are listed 'Best First'.
Re: Re: Re: Unsafe signals are called "Unsafe" for a reason, you know by jfroebe (Parson) on Mar 19, 2004 at 18:27 UTC
Actually, I completely understand the ramifications of using the unsafe signals... Making a blanket statement is not necessarily wise... there are almost always exceptions to the rule. The fact remains that there are instances where the unsafe signals are required (say for timeouts involving DBD::Oracle). Avoiding the unsafe signals should be done when possible, when it is unavoidable, prepare for the worst. The perl engine should be fixed to make these 'unsafe' signals to be 'safe' (other engines are able to do this... so I see no reason why the perl engine can not be fixed). Until that happens, we will have to use unsafe signals when absolutely necessary and when there is no other option. Once again, the 'trading systems' was just an example of short maintenance windows.	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Unsafe signals are called "Unsafe" for a reason, you know
by jfroebe (Parson) on Mar 19, 2004 at 18:27 UTC

Actually, I completely understand the ramifications of using the unsafe signals...

Making a blanket statement is not necessarily wise... there are almost always exceptions to the rule.

The fact remains that there are instances where the unsafe signals are required (say for timeouts involving DBD::Oracle). Avoiding the unsafe signals should be done when possible, when it is unavoidable, prepare for the worst.

The perl engine should be fixed to make these 'unsafe' signals to be 'safe' (other engines are able to do this... so I see no reason why the perl engine can not be fixed).

Until that happens, we will have to use unsafe signals when absolutely necessary and when there is no other option.

Once again, the 'trading systems' was just an example of short maintenance windows.

[reply]