Re: GNAT: Setting SIGPIPE to SIG_IGN

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Florian Weimer wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>>Florian Weimer wrote:
>>
>>>I want to instruct the GNAT run-time library that it sets the SIGPIPE
>>>handler to SIG_IGN, so that system calls such as read() return EPIPE
>>>instead of delivering a signal.
>>
>>Actually, I think you mean that read(2) returns EINTR (or EAGAIN
>>on some platforms). EPIPE is returned when you write to a
>>pipe without a reader.
> 
> It depends on the protocol.  I believe that TCP implementation behaves
> in the same way (as you describe it), but some other networking
> protocol implementations deliver SIGPIPE even on recvmsg() etc.

Interesting. It doesn't sound unreasonable.

>>>This might sound like a silly question (I can write the necessary call
>>>to signal(2) myself), but I don't want to work around the GNAT
>>>run-time library.  Any suggestions?
>>
>>I know what you're driving at. You'll need to know what GNAT is doing
>>by default. I suspect that the SIG_DFL is the default for the SIGPIPE
>>signal. SIG_DFL's meaning varies by signal on a particular host. But by
>>default, for SIGPIPE, it defaults to delivering the signal usually.
> 
> The default for SIGPIPE is to terminate the thread, which is a bit too
> drastic for my taste.

Yes.

>>You can approach this from two angles IMO:
>>
>>1) Establish a signal handler in Ada, and ignore the signal (this will
>>    "catch the signal", and still cause EINTR to be returned for blocked
>>    system calls like read(2), when the handler returns).
> 
> It will cause EPIPE to be returned, so it works the way I want.  (I
> assumed that setting the handler to SIG_IGN had some magic side
> effect, similar to other signals, but this is not the case.)
> 
> However, this pulls in the tasking run-time library which has got very
> problematic side effects, at leat on GNU/Linux.

Hmmm, I see.

>>2) Deal with it in C terms, using SIG_IGN, which will have the same
>>    effect without having to specify a handler (the less code approach).
> 
> There is a problem with LinuxThreads (the threading implementation
> provided by the GNU libc): signal handlers are thread-specific, so it
> is not sufficient to set the handler in a single thread (GNAT
> compensates for this, but you would have to do it on your own here).

Is there anything useful you can learn from the "GNAT compensation"
that might help?

I'm afraid I don't see an easy solution. I think the approach
I would take is to attempt to solve the "problematic side effects" in
the "tasking run-time library". But this probably doesn't work well
for a project that must "port" to multiple platforms (you haven't said
much about the project requirements), or port to many future releases
of Linux. (One possibly useless suggestion is to try FreeBSD instead ;-)

The only other possibility would be if you knew of a way to iterate
over all known threads in C. I am not aware of a Linux way to do this,
though there might very well be (perhaps one way is to walk the
errno array implementation, checking for valid threads).

Beyond that, I can't think of any further useful advice. I do
believe that you do have an interesting problem.

In fact, this problem interests me, now that I think of it.
Any GNAT project written for Linux that must intercept SIGINT
(for example), has a challenge ahead of them if tasking is
used and the library has significant side-effects.

Would you be willing to elaborate on the "problematic side effects"?
Are they problems for your typical Linux tasking app in GNAT? I
currently develop on FreeBSD, but by no means want to limit my
Open Source projects to one platform.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg