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

On Wed, Nov 03, 2010 at 10:29:18PM +0100, Jens Rehsack wrote:
> 2010/11/3 Martin J. Evans <[email protected]>:
> [...]
> > From time to time something similar to Brian's post turns up on this list although it is usually something to do with pipes not working as you expect.
> >
> > 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.

> > 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.