Re: GNAT: Setting SIGPIPE to SIG_IGN

[Florian Weimer <fw@deneb.enyo.de>]

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

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

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

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