Re: GNAT: Setting SIGPIPE to SIG_IGN

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

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.

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

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

> The RM interfaces do not appear
> to be helpful here because I think that if no handler is attached, the
> default handler is invoked, which is not what I want.

Actually, I believe there is no handler at all (the process just
aborts, based upon a O/S "system" action specified by SIG_DFL for
SIGPIPE).

I believe GNAT leaves the setting as SIG_DFL. You can check this by
calling a C program that retrieves the current setting and comparing
it against SIG_DFL.  If this is the case, then GNAT is doing nothing
with the signal (not handling it), but the O/S is permitted to raise
the signal (the default system action occurs).

I havn't yet fully dug into this, but I do believe there was a signal
names related change after GNAT 3.13p, since my signal code would not
compile on gcc-3.1.1 when I tried it (I think the signal name definitions
moved to a child package.) So approach # 2 might be "more portable",
but I am just guessing with a poor memory ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg