On 07/11/10 20:14, Tim Bunce wrote: > 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.
I am aware of the SIGCHLD problem, which affects only connections using the BEQ connection method, being a fre1quently asked questions. The solution is to add "BEQUEATH_DETACH=YES" to the client side sqlnet.ora. I have found several threads about SIGINT, but all seem to peter out without reaching a conclusion. >>> 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. I can say whether a workaround would be a good idea without understanding exactly what the problem is. I can't reproduce the original poster's problem, and I don't know why. -- Charles Jardine - Computing Service, University of Cambridge c...@cam.ac.uk Tel: +44 1223 334506, Fax: +44 1223 334679
