[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Re: SIGPIPE handling

From: Markus Gothe
Subject: Re: [Gnash-dev] Re: SIGPIPE handling
Date: Mon, 18 Oct 2010 12:04:33 +0200

Hash: SHA1

On 15 Oct, 2010, at 02:50 , John Gilmore wrote:

>> -        bytesSent = ::send(_socket, buf, toWrite, MSG_NOSIGNAL);
>> +        // I'd like to get no SIGPIPE here, as we wouldn't
>> +        // know how to handle. Instead, for broken pipe I'd
>> +        // prefer being notified with a return of -1.
>> +        // Is that possible, in a standard way ?
>> +        // MSG_NOSIGNAL was reported as being non-standard flag..
>> +        bytesSent = ::send(_socket, buf, toWrite, 0);
> The usual way is to do:
>    signal(SIGPIPE, SIG_IGN);
> which says to ignore that signal rather than deliver it.  This is a
> stateful setting, which remains set until the process ends or you
> change it.  This is a portable construct (though most other uses
> of signal() are not portable).

I think sigaction() is preferable under any circumstances even though
this one is portable. The problem is that sighandler_t is a GNU libc
extension which isn't defined in BSD libc etc. However we can define it
pretty easy as a pointer to a callback.

> The return value can be used to re-establish the former SIGPIPE
> handler if you want; or it can just be thrown away if you're doing
> this in mainline (rather than library) code and you know you don't
> ever want to restore the default or former setting.

Yes, this is an issue with signal() and return values, which must be taken
care of as a callback-pointer.

>       John

I'll digg into sigaction() later tonite if those damn headhunters stop calling 
me. ;-)

> _______________________________________________
> Gnash-dev mailing list
> address@hidden

//Markus - The panama-hat hacker

Version: GnuPG/MacGPG2 v2.0.14 (Darwin)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]