2 Answers
2

The code in that example works hard to localize the change to just that section of code, or any code called from it.

There is not 100% guarantee that no code will be effected outside the code that bypasses safe signals, because signals are no longer safe. In the example the call being timed out is a DBI->connect. For most DBD's this will be implemented mostly in C, unless the C code can handle being aborted and tried again you might find that some data structures internal to the DBD, or the libraries it uses, are left in a inconstant state.

The chances of the example code going wrong is probably incredibly tiny. My personal anecdote on the issues is that I had used the traditional Perl signal handling for years before safe signals were introduced and for a long time I had never had a problem. I hadn't even been very cautious about what I did in my signal handlers. Then we managed to hit a data set that actually did trigger memory corruptions in about 1 out of ever 100 runs. Just modifying the signal handlers to use better practices, similar to those in the example, eliminated our issues.

The question is not very good. I would like to know if a script with such a signal handling could affect for example other scripts/processes. I don't believe it but I still ask for security.
–
sid_comAug 22 '12 at 18:13

The question is not very good. I would like to know if a script with such a signal handling could affect for example other scripts/processes. I don't believe it but I still ask for security.
–
sid_comAug 22 '12 at 18:14

1

Not directly, no. It only changes that process's signal handling.
–
ikegamiAug 22 '12 at 18:16