httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject RE: errnos and buff.c
Date Thu, 17 Dec 1998 03:48:49 GMT
On Wed, 16 Dec 1998, RobS wrote:

> > Yea.  There are other issues with how Apache currently deals with errors
> > that are somewhat broken.  The whole r->connection->aborted thing is
> > hokey, since it will possibly sometimes get set if there is an error
> > writing to the client or a timeout, but maybe not.
> Apache core uses r->connection->aborted in many places.

That is different.  It is using it and checking it in the same places.
Many of the functions check if there has been an error right off the top, 
then r->connection->aborted is just used for particular circumstances.

No, the places it uses it aren't necessarily entirely logical.

> > Personally, we really need to ensure that module authors know that they
> > must be checking the return codes for Apache functions that they call and
> > that, generally, any failure should be treated as permanent.  Then we can
> What is it that prevents fixing r->connection->aborted so it works as
> expected?

Because various buff.c API functions don't have r->connection so they
can't set r->connection->aborted, and you can't rely on the caller setting

> > get rid of the SIGPIPE handler, which causes problems trying to use other
> > sockets from with Apache modules and isn't entirely reliable anyway.
> Why is the SIGPIPE handler causing problems in module sockets and why isn't
> it reliable?  I can see how a SIGPIPE based on a read/write from a socket
> other than current_conn->client is a problem, but not how the handler causes
> problems in other sockets (of course if hard_timeout is in effect the
> longjump/clear_pool will close them).

Because SIGPIPE isn't always delivered when you have a problem with the
socket, only in certain cases.  It is really redundent info if you already
have your code checking return values, which they have to do anyway. 

On Wed, 16 Dec 1998, RobS wrote:

> > Unfortunately, it leads to the situation where a silly library can set an
> > alarm() but, for whatever reason, not clear it.  Since Apache hasn't set
> > any, it won't clear it when the request is over either.  That means that
> > in the middle of some random request (or possibly when there isn't even a
> > handler installed) Apache will get that SIGALRM and abort the connection
> > or kill the child.  Sigh.  I hate unix.
> ap_set_callback_and_alarm(NULL, 0) is called at the top of the request loop.

That doesn't matter, since OPTIMIZE_TIMEOUTS means that the child doesn't
set the alarm()s so that function doesn't actually set the alarm.  Hence,
the "leads to the situation..." when talking about Dean's timeout

On Wed, 16 Dec 1998, RobS wrote:

> > If you want to use a hard_timeout, then I don't think I can really
> > recommend that too greatly, but you still have to deal with error returns
> > from functions.  Well, you can currently get by without doing so since the
> > SIGPIPE will make things work after a few failed writes but that isn't
> > reliable nor is it a long term solution since it currently causes
> > problems with other sockets that modules may open plus it isn't
> > sustainable in a threaded model.
> Why is hard_timeout bad?  I thought it was one of those neato features
> (aaaaaaaa, times up, your outa here).

Yea, in theory.  In reality, longjmp()ing out of arbitrary code really
doesn't work too well.  There are all sorts of things, from locks to
memory allocation to open files to voodo magic that a function can be
doing when you jump out.  longjmp()ing out gives it no way to cleanup.

Now, using a soft_timeout means that you can get stuck in that function
forever, but a well behaved function can prevent that.

> What do you expect the threaded solution will look like?

The only difference has to be that SIGPIPE can't be used, so there will be
no setting of r->connection->aborted when we get a SIGPIPE.  Well, plus
there are even more possible consequences to longjmp()ing out of stuff in
a threaded program.

View raw message