Re: GNAT: Setting SIGPIPE to SIG_IGN

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

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

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

Ugh, I can't do that.  If tasking is activated, setuid(2) and similar
system calls do not work reliable on GNU/Linux: Credentials are thread
attributes, not process attributes as required.  And there's somethign
which makes matters even worse: The pthreads library uses signals
for communication with the management thread, and if I change the
credentials, the signals cannot be delivered any longer because the
permission check fails, and the program just stops.  This problem is
triggered not only by the active use of tasking, it's sufficient to
declare a single protected object.

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

I'd like to have as few as GNU/Linux dependencies as possible.  In
fact, last weekend, I've made some changes (see my other message about
C expression evaluation using autoconf) which should port my little
pet project to any POSIX platform on which GNAT binaries can run.

> or port to many future releases of Linux.

Linux isn't the problem here, it's the threading implementation in GNU
libc.  I wouldn't have to face this problem if I was using FSU
Threads, for example, or if I'd wait a few months (years?) until the
GNU libc implementation is conforming to POSIX.

> (One possibly useless suggestion is to try FreeBSD instead ;-)

Perhaps after the first big security incident Debian has to
experience. ;-)

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

Well, fortunately my fundamental assumption is wrong: signal handlers
are not thread specific, although signals are always thread-specific
(which differs from what POSIX says).  As a result, I can call
signal(SIGPIPE, SIG_IGN) during elaboration.  Case closed.

(Well, I better write a test case for that, but looking at the actual
source code, I think this should work, and all the complexity isn't
required.)