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

On Sun, Nov 07, 2010 at 08:14:47PM +0000, Tim Bunce wrote:
> > > I have to say I would be strongly against returning all signals to
> > > their original state after a connect call. I know for a fact that
> > > some oracle clients (depending on how you connect to Oracle) install
> > > a SIGCHLD handler for instance. Who is to say what operations in the
> > > Oracle client library might be rendered useless if we destroy any
> > > signal handlers it has set up.
> >
> > There is an entry in Oracle Knowledge Base about this. I had trouble
> > with this in a project around a year ago - and under specific
> > circumstances it's safe to restore the handlers and in others you
> > should chain them (when you need them, too).
> > 
> > Search for SIGCHLD in the knowledge base (I didn't took the URI with
> > me when I left the contractor).
> 
> The topic has also come up on the dbi mailing lists several times over
> the years. Both for SIGCHLD and SIGINT.

Also, for more background and related issues, see the notes relating to Oracle in:
http://search.cpan.org/~lbaxter/Sys-SigAction-0.11/lib/Sys/SigAction.pm#DESCRIPTION

Tim.

> > > Is it really worth changing DBD::Oracle for what effectively is a one liner?
> > 
> > No, because it's not safe for each Oracle configuration. It must keep up to the
> > developer to figure out when it's safe.
> 
> I think we should try to fix/workaround at least the SIGINT issue.
> The default behaviour should be to act in the most reasonable/useful way.
> An option could be provided to restore the current unreasonable way.
> 
> Tim.