On Wed, Nov 03, 2010 at 10:29:18PM +0100, Jens Rehsack wrote: > 2010/11/3 Martin J. Evans <martin.ev...@easysoft.com>: > [...] > > 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.
