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

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

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
[email protected]    Tel: +44 1223 334506, Fax: +44 1223 334679