client connection questions

[Doug MacEachern <do...@pobox.com>]

A few questions:

If ap_rwrite/ap_bwrite returns -1, does that *always* mean the connection
is broken?  

r->connection->aborted is only set if a soft_timeout happens, why not with
hard_timeout too?

What is the "right" test to find out if the connection has been broken? 

Here are two checks that seem right by eyeballing the source code, but
leave eyes sore.

if(r->connection->client->flags & B_EOUT) {
    ... connection was broken ...

if(r->connection->client->fd < 0) {
     ... connection was broken ...

Both hard_timeout() and soft_timeout() will set the B_EOUT flag and
client->fd is set to -1 when ap_bclose is called in both cases.

-Doug

Re: client connection questions

[Marc Slemko <ma...@worldgate.com>]

On Wed, 2 Sep 1998, Doug MacEachern wrote:

> At 03:15 PM 9/2/98 -0600, Marc Slemko wrote:
> >On Wed, 2 Sep 1998, Doug MacEachern wrote:
> >
> >> A few questions:
> >> 
> >> If ap_rwrite/ap_bwrite returns -1, does that *always* mean the connection
> >> is broken?  
> >
> >It means you can't write to it any more and shouldn't retry AFAIK.
> 
> That's what I thought, but would like to be 100% sure.  For quite some
> time, mod_perl wasn't even checking if the return value from rwrite was <
> 0.  After that check when in, a user claimed some of his scripts were not
> printing everything they should.  I put the check for 
> if(r->connection->aborted) break;
> else continue;
> Which, now I understand would always continue.
> 
> hmm, ap_send_fd_length() checks errno:
> 
>             else if (w < 0) {
>                 if (r->connection->aborted)
>                     break;
>                 else if (errno == EAGAIN)
>                     continue;
> 
> What would cause errno == EAGAIN?  Is this something all modules should check?

EAGAIN is what you get if you try to do something on a nonblocking socket
that would block.  Not sure why it is used there, you shouldn't have to
worry about it that I cna think of.

> 
> >> 
> >> r->connection->aborted is only set if a soft_timeout happens, why not with
> >> hard_timeout too?
> >
> >Because if a hard timeout happens, your code will never be in a position
> >to see the r->connection->aborted.  
> 
> Right, I should have known that by now.  But, you could see in a logger or
> register_cleanup() function.  

True.  

Re: client connection questions

[Doug MacEachern <do...@pobox.com>]

At 03:15 PM 9/2/98 -0600, Marc Slemko wrote:
>On Wed, 2 Sep 1998, Doug MacEachern wrote:
>
>> A few questions:
>> 
>> If ap_rwrite/ap_bwrite returns -1, does that *always* mean the connection
>> is broken?  
>
>It means you can't write to it any more and shouldn't retry AFAIK.

That's what I thought, but would like to be 100% sure.  For quite some
time, mod_perl wasn't even checking if the return value from rwrite was <
0.  After that check when in, a user claimed some of his scripts were not
printing everything they should.  I put the check for 
if(r->connection->aborted) break;
else continue;
Which, now I understand would always continue.

hmm, ap_send_fd_length() checks errno:

            else if (w < 0) {
                if (r->connection->aborted)
                    break;
                else if (errno == EAGAIN)
                    continue;

What would cause errno == EAGAIN?  Is this something all modules should check?

>> 
>> r->connection->aborted is only set if a soft_timeout happens, why not with
>> hard_timeout too?
>
>Because if a hard timeout happens, your code will never be in a position
>to see the r->connection->aborted.  

Right, I should have known that by now.  But, you could see in a logger or
register_cleanup() function.  

-Doug

Re: client connection questions

[Marc Slemko <ma...@worldgate.com>]

On Wed, 2 Sep 1998, Doug MacEachern wrote:

> A few questions:
> 
> If ap_rwrite/ap_bwrite returns -1, does that *always* mean the connection
> is broken?  

It means you can't write to it any more and shouldn't retry AFAIK.

> 
> r->connection->aborted is only set if a soft_timeout happens, why not with
> hard_timeout too?

Because if a hard timeout happens, your code will never be in a position
to see the r->connection->aborted.  

If rwrite is returning -1 and you are in a hard timeout and you are still
in your code, then timeout() was _not_ called because Apache did not
figure out that the connection was closed via SIGPIPE, so setting
r->connection->aborted there is nonsensical.

> 
> What is the "right" test to find out if the connection has been broken? 

If you are in a hard timeout, you "shouldn't" be left there if the
connection is broken, but since SIGPIPE is a bad idea then it could
happen.  So all you have to do is be sure to check your return values from
output functions.