Re: $SIG{INT} tampering during DBI->connect on Oracle

On 11/2/2010 2:49 PM, Brian Phillips wrote:
> Hello - I recently discovered that when we do a DBI->connect to an Oracle
> database, the process no longer responds to SIGINT signals.  I'm not sure if
> it's something in DBD::Oracle (I can't find anything messing with $SIG{INT})
> or something in the Oracle client itself but the fix is relatively simple
> and I'm hoping it can be included in DBD::Oracle (unless there's a downside
> I'm not seeing).
>
> Here's some code that illustrates the problem:
> http://gist.github.com/660058#file_dbd_oracle_sigint_fail.pl
>
> Basically, the forked child process discards the SIGINT signal once it's
> done a DBI->connect.
>
> The workaround seems fairly simple (a single-line change from the above:
> http://gist.github.com/660058#file_dbd_oracle_sigint_works.pl):
>
>    {
>      local $SIG{INT}; # make sure $SIG{INT} returns to normal after we
> leave this block
>      $dbh = DBI->connect('dbi:Oracle:mydb', 'user', 'password');
>      warn "connected in child ($$)\n";
>    }
>
> Is this something that would be appropriate to go in the
> DBD::Oracle::dr::connect
> sub? I have not checked any other signal handlers besides INT and TERM (TERM
> seems to work fine) but perhaps it'd be better to localize the entire %SIG
> hash:
> local @SIG{ keys %SIG };
>
> Thoughts?
> Brian
>
Sounds like a good Idea.  I could include it but is it 'safe'  We will 
have to here from types that know something more
about SIGINT signals than I do.

My one question is how OS transportable is this?

Just for example If I am working on windows does SIGINT have any effect?


Like to here what the other Maintainers say?

Cheers
John