[Issue 1491] New: if working with timed-out socket, SIGPIPE will kill program

[Ingo Oeser]

Downs wrote:

> Ingo Oeser wrote:
>> Signals are a global state.
>> 
>> Libraries should never modify them in that manner, since
>> the defaults are well documented in signal(7) and programs
>> might expect this behaviour.
> Unix signals are a platform specific feature that somebody writing a
> platform independent program should _not_ have to mess with.

Then simply don't touch them in a manner visible to the user.
Doing that is as useful as keeping locks open, which is also
not documented. Principle of least surprise should be applied here.

If you write a Unix daemon (sth. like a service in Windows),
you need to handle signals in a defined way. There is no way around
that, since your desired behaviour depends on your needs.

Face it: Windows and Unix are so different, that anything more complex
        than "hello world" needs to handle the subtle differences anyway.

>> The default setting for SIGPIPE is to terminate the program,
>> which is correct for simple programs not handling signals at all.
>> 
> But this behavior is neither documented in std_socket.html, nor is it
> platform independent, 

Interaction of between phobos and Unix systems is not documented 
in any *.html at all.

This leads to hard to find bugs, since many API details are only documented
in the man pages on Unix systems and the API is implemented in the matching
C libraries (e.g. the glibc on Linux). I'm happy, that I have the sources
of the standard library to be able to find such side effects :-)

> nor is there a platform independent way to 
> _prevent it_.

Correct! By googling around a bit I found another way to do this, 
if MSG_NOSIGNAL is not available: setsockopt() with SO_NOSIGPIPE.
This might prevent the same problem on MacOS X. But I don't have the docs
for that one.

If everything else fails, one can ignore SIGPIPE before send() and sendTo()
and restore the old signal behaviour after the call. That is inefficient,
but at least correct and as transparent as possible.

> Okay, well great! If there's a proper way to suppress this behavior, by
> all means, let's do that instead! But please, don't force the user to
> write platform dependent code. That's what standard libraries are for.

Of course not! Yes, but the standard library is also the one, which
has to be compatible in program behaviour with any other library.

How useful is a standard library, which doesn't work with millions
of lines of code written already?

I like revolutionary ideas, but the should integrate in practise.


Best Regards

Ingo Oeser