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.
