On 11/2/2010 2:49 PM, Brian Phillips wrote:
Sounds like a good Idea. I could include it but is it 'safe' We will have to here from types that know something moreHello - 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
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
