From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,400599f96e15af9b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-09-01 03:16:17 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!syros.belnet.be!news.belnet.be!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!news.belwue.de!news.uni-stuttgart.de!news.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: GNAT: Setting SIGPIPE to SIG_IGN Date: Sun, 01 Sep 2002 12:16:16 +0200 Organization: Enyo -- not your organization Message-ID: <87lm6maubz.fsf@deneb.enyo.de> References: <87ofbj5q0r.fsf@deneb.enyo.de> <3D71318A.10909@cogeco.ca> NNTP-Posting-Host: deneb.enyo.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: cygnus.enyo.de 1030875371 1822 212.9.189.171 (1 Sep 2002 10:16:11 GMT) X-Complaints-To: abuse@enyo.de NNTP-Posting-Date: 1 Sep 2002 10:16:11 GMT Cancel-Lock: sha1:jT+KtAJxu+D8FxHrHmuq9ZmUIUg= Xref: archiver1.google.com comp.lang.ada:28641 Date: 2002-09-01T10:16:11+00:00 List-Id: "Warren W. Gay VE3WWG" 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).