Subject: [clisp-list] Re: read-line (clisp 2.30/woody) - SIGPIPE

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Mon Jan 20 00:55:02 2003

Hi,

>>   as told - the user will use some MUD client - they could always
>>   close quit or crash. So SIG_PIPE will be a common situation.
>CLISP catches it.  you, the CLISP user, should not see it.

Maybe Michael did not tell us everything about his exact setup. While I can't image why SIGPIPE would have anything to do with socket communications, it could be his particular environment which generates SIGPIPE in addition to closing sockets.

E.g. mod_fastCGI does exactly this for Apache:
"If an http client aborts a request before it completes, mod_fastcgi does too - this results in a SIGPIPE to the FastCGI application. At a minimum, SIGPIPE should be ignored (applications spawned by mod_fastcgi have this setup automatically). Ideally, it should result in an early abort of the request handling within your application and a return to the top of the FastCGI accept() loop."
http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html

Note that mod_cgi can talk to the spawned application using either pipes or sockets. SIGPIPE can be issued by mod_fastcgi in both cases (assuming that despite using sockets, the application is running on the local machine).

Regards,
	Jorg Hohle.

---

From: Randall R Schulz <[email-masked]>
Date: Mon Jan 20 08:48:04 2003

Joerg-Cyril,

At 00:52 2003-01-20, Hoehle, Joerg-Cyril wrote:
>Maybe Michael did not tell us everything about his exact setup. While I 
>can't image why SIGPIPE would have anything to do with socket 
>communications, it could be his particular environment which generates 
>SIGPIPE in addition to closing sockets.

Unix systems do generate SIGPIPE when attempting to write to a socket that 
has been shut down in the outgoing direction. I don't know about Windows 
but I'd expect (without assuming) that Cygwin does the same.

In an ordinary command-line pipeline setting, the shell does not report 
SIGPIPE since they occur whenever a down-stream application in a pipeline 
quits without processing all its input. A common example is using a page 
such as "more" or "less" and typing the 'q' command before all the input 
has been displayed. Because SIGPIPE is "normal", the shell doesn't report 
it and many people don't know how common its occurrence really is.

>"If an http client aborts a request before it completes, mod_fastcgi does 
>too - this results in a SIGPIPE to the FastCGI application. At a minimum, 
>SIGPIPE should be ignored (applications spawned by mod_fastcgi have this 
>setup automatically). Ideally, it should result in an early abort of the 
>request handling within your application and a return to the top of the 
>FastCGI accept() loop."
>Note that mod_cgi can talk to the spawned application using either pipes 
>or sockets. SIGPIPE can be issued by mod_fastcgi in both cases (assuming 
>that despite using sockets, the application is running on the local machine).
>
>Regards,
>     Jorg Hohle.

Randall Schulz